Do we know exactly what it’ll be yet? Not quite. We have some hints… but until it’s released… we’ll continue to speculate.
While I am not one to make predictions—I do have a few theories about what Atom will not do for us. (if you’re looking for a new business idea… feel free to snag any of these)
1. Atom Editor will not make it easier to code while in the shower. While I would love to take advantage of putting my thoughts to code while letting my conditioner do it’s thing… I don’t believe they’re trying to solve this problem (yet).
2. Atom Editor is not going to make it difficult for me to produce shitty code. To date, nearly every code editor on the market is focused on making it easier to produce code…. good AND/OR bad. Where is the editor that tells us to quit while we’re head. “Are you serious, Robby? Have you seen what you’ve been writing today? Just stop. Go outside. Take a break and try again tomorrow.”
3. Atom Editor will not bring synergy to developers.
4. Atom Editor will not change the music playing to compliment the coding problem that I’m faced with. If my tests aren’t passing… I wish my music would keep me calm and focused. This is not a time to start playing WHAM! (…or maybe it is)
5. Atom Editor will not bring about peace in the Emacs vs Vim wars. We are going to have to let them sort a peace deal on their own.
6. Atom Editor will not have integrated CVS or Subversion support when it is released.
7. Atom Editor will not promise the world to you like Visual Studio.NET did back in 2002. I remember their demo videos and it seemed like the development world was about to change! I never would have guessed that come 2005, I’d be in love with something as simple and fancy-feature-less as TextMate.
8. Atom Editor will not just be a clone of Sublime Editor. Github has too clever a team for that objective.
What are you confident that Atom Editor will not be?
8 for 8!
I fucked up this last week.
On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.
The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)... I ended up running a few tests locally and pushed it out to production.
I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.
It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.
So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.
Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.
If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.
In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.
What was your latest failure?