Atomic Object Detroit recently assessed dozens of candidates to find a summer development intern, and we’re continually receiving applications for full-time developers.
As I reflect on the candidates that I’ve assessed both here and at previous companies, I’m struck by how revealing each candidate’s first email correspondence is. Those who’ve left strong, positive first impressions on me and my team have almost always made it far in the interview process, while everyone else has almost never worked out well, even if we advanced them to a later stage initially.
It’s one thing to develop and test a Windows application; it’s quite another to bundle it up into a nice executable that installs correctly on all the different Windows versions that you need to support. I’d like to guide you through the process that I wish I had when I was creating my first installer. Read more on Quick-Start Guide to Creating a Windows Installer…
Protractor Page objects provide a helpful way to organize your end-to-end test code. While your actual tests take actions and make assertions about how your application should respond, page objects encapsulate the details of how to perform those actions on a page. Read more on Protractor Page Objects…
Git is a powerful tool that we love as developers. It’s also complicated. I consider the bare essentials of Git, the minimum set of features to be familiar with before we can be productive, to be all of this:
local interaction: status, add, remove, commit, reset, checkout
When our Backbone.js apps become complicated, we need to utilize Backbone’s EventAggregator. From the Marionette docs: “An event aggregator is an application level pub/sub mechanism that allows various pieces of an otherwise segmented and disconnected system to communicate with each other.”
1. Make sure you need it.
It’s harder to follow the execution of an event-based program than of regular synchronous method calls, so make sure you understand why you need an event in the first place. It’s worthwhile to ask: if events weren’t available, what would I have to do to solve this problem? Read more on Backbone Event Best Practices…
If you’re a developer shopping for a new MacBook, choosing a CPU can be confusing. Apple always gives you a handful of different CPUs options, all with different specs and prices, but it’s very difficult to understand how your development experience will be affected by this choice.
You can put thought into the other options that Apple lets you customize. For hard drive capacity, it’s easy to check the amount of space you’re using on your current machine and decide on a hard drive size for your new machine. If you’re comparing two different screen sizes, you can decide if you’d rather have a cheaper and lighter machine or a larger screen.
How far should we take unit testing? Should every line of code be covered by a unit test? What about code that’s hard to test? Let’s look at the cost and value of unit testing in a couple of different situations.
Tests We Can All Agree On
It’s easy to see the value of unit tests when we’re writing actual functions. Let’s say we’re writing a helper function called next_valentines_day for our greeting card application. Here are some tests that we might write:
describe next_valentines_day do
it "returns next year's valentine's day when after Feb 14"do
it "returns same year's valentine's day when on Feb 14"do
Even from just these two tests, we we’ve significantly reduced the risk of calculating the wrong Valentine’s day in our software. And that means we’re less likely to lose valuable time fixing bugs in the code or dealing with other fallout from the code being wrong (like decreased greeting card sales). Read more on The Cost of Unit Testing…
At retrospective meetings, we reflect on how our team has been operating, sharing both the good and the bad. We try to identify problems and take actions that solve those problems.
But just as important as fixing procedural problems is giving individual team members the chance to speak, be heard, and “air-out” anything that’s been bothering us. Ideally, we will honestly share our feedback and perspectives, and humbly acknowledge our mistakes. In reality, though, most of our retros fall short of that standard. Here are some common problems and ideas to help work through them. Read more on Tackling Silence, Avoidance, & Negativity in Project Retrospectives…
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 on Dumb Development Mistake Checklist…