Why You Should Never Use the Word “Obviously”

One of our core values at Atomic is Teach and Learn. This belief is evident in many different aspects at Atomic, from the external (presenting and attending conferences) to the internal (setting up brown bag presentations and weekly cross-team design reviews). It is also clear in the day-to-day work, like pairing and problem solving as a unit instead of as individuals.

As I’ve spent time learning and listening to the great teachers we have at Atomic, I’ve noticed one word missing from nearly everyone’s vocabulary: “obviously”. Read more on Why You Should Never Use the Word “Obviously”…

10 Tips for Running an Elementary School Computer Club

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 on 10 Tips for Running an Elementary School Computer Club…

Creating Common Ground with the Atomic Reading List

Atomic Object has employees from many different backgrounds. Though this diversity is something we celebrate in our culture, it could potentially lead to a team using several conflicting approaches on the same project. To help mitigate this risk, Atomic’s new employee orientation aims to create common ground with required reading.

The Atomic Curriculum

New Atoms are required to read Atomic Spin and Great Not Big post about things like Atomic’s values, our dedication to transparency, our project budgeting model, and how we like employees to engage in teams.

And all makers must read three books during their first six weeks at the company: Read more on Creating Common Ground with the Atomic Reading List…

New Job? 3 Tips for Overcoming Your Fear

I had a lot of assumptions, expectations, and fears starting as a developer right out of college. Partly because it was my first full-time, professional job as a software developer. But on top of that, I was starting at Atomic Object. If you were a Computer Science major at Grand Valley State University, you knew Atomic Object. I remember I attended a “speed interview” exercise while attending Grand Valley where Atomic Object was present — the buzz of the entire room was that Atomic Object was there. Needless to say, I was nervous and overwhelmed.

Over the past year, I’ve learned a few things that I think can apply to anyone starting in any field right out of college. Read more on New Job? 3 Tips for Overcoming Your Fear…

Shared Understanding: Building Languages and Communities Around Software

Sometimes it’s hard to say the thing we want to see.

As a dad, I’m fascinated by human language development; and as a software maker, I’m constantly engaged in sharing mental models. Atoms spend a lot of time communicating with customers to bring a shared vision to reality. Reflecting on that practice, I recently discovered a sociological model that ties together language and shared understanding, called “interactionism.” Read more on Shared Understanding: Building Languages and Communities Around Software…

How Do You Know What You Don’t Know?

I joined Atomic Object last summer as an apprentice. I was eager to learn and work with people who give a shit about what they do. As an apprentice, I wasn’t expected to be an expert, but I was expected to soak in as much knowledge in three months as humanly possible. I quickly found that there was a lot I didn’t know and a lot that I didn’t have a deep understanding of.

But how could I ever know what I don’t know? I came up with three criteria to help me determine how well I understand a particular topic.

Read more on How Do You Know What You Don’t Know?…

Learning to Type

One of my biggest struggles as a developer is probably something a lot of people, particularly software professionals, take for granted. I don’t know how to touch type. Growing up, I was never enrolled in any type of keyboarding class in grade school. I was also never more than a casual computer user until the end of my first year of college, which gave me plenty of time to form bad habits.

The worst part is that, even though I was always aware of my problems with typing in the back of my mind, I was never aware of how impactful of a problem it was until I began to work full time at Atomic. While I can type marginally quickly (~30 WPM) using my practiced hunting and pecking, pair programming has revealed that I have a handicap compared to my fellow developers when it comes to being able to quickly put out code, and it’s embarrassing. I have also noticed that on particularly long days, especially when I am working by myself, I have begun to develop headaches from the frequency with which my eyes continually dart between my screen and keyboard.

Read more on Learning to Type…

Code Reading

I was recently asked if I had any advice for reading code. It’s an important skill for developers, because practice reading code leads to faster ramp-up on projects. Studying good codebases is also one of the best ways to pick up a sense for project architecture design.

1. Find Your Point of Entry

First, there’s the question of where to start. If I’m trying to get a sense for how a system fits together a whole, its main point of entry is an obvious starting place. Often, though, I’m more interested in a particular feature — understanding why awk’s implementation of regular expressions can run laps around the one in Ruby, or a cool trick like Chicken Scheme‘s “Cheney on the MTA“-based garbage collector.

Read more on Code Reading…

Lessons in Teaching & Learning – Why Intelligence Isn’t Enough

In my time at Atomic Object, I’ve had the opportunity to teach and mentor a number of apprentices. These teaching experiences have given me an idea on what attributes make up a good teacher and student. However, I had never formalized or put into words what these attributes are until I listened to Education and the Internet and How Children Succeed from EconTalk.

Read more on Lessons in Teaching & Learning – Why Intelligence Isn’t Enough…

Fighting Dogmatism with Fresh Perspectives

It is unfortunately easy to forget the depth of the lessons that have led us to our current software development practices. However, I’ve found it’s similarly easy to be forced to recall them — work with someone new.

I’ve had the pleasure this summer of working with two folks new to AO: Nick Reynolds, an intern who will be returning for his senior year at MSU shortly, and Jesse Hill, an experienced software developer with an especially strong background in mobile and Java. Both have taken to our ASP.NET MVC web application development project swimmingly. One of the things I’ve really enjoyed about working with these two is that they ask questions — good questions that force me to recall the important lessons that have lead to my current practices on this project.

Read more on Fighting Dogmatism with Fresh Perspectives…