My dirty little secret as a developer is that I’ve been an Android user for the past 2 years. I finally upgraded this week to an iPhone. I can’t begin to describe how much better the experience it is!
Category Archives: Other
More On The Whole “Learning to Code” Thing
Scott Hanselman wrote an excellent piece on the “learning to code” discussion that occurring (still) on sites like HackerNews. I feel he gets closer to the point of Atwood’s original idea. Maybe a different angle. The point is that you should learn to code if you have a burning desire to and more importantly if you have a need to.
Bloomberg would do well to learn how the internet works, but coding is not necessarily a requirement. Same goes for Congress — because they have to deal with and legislate technological issues. If you own a sink you should learn a bit about plumbing to know how it works. Water doesn’t simply materialize out of thin air and enter the faucet and it doesn’t just evaporate in the drain. Just as plumbing is a means to have a running water system in your house. Coding is likewise a skill to be used to create larger systems but it’s no more a solution to anything any more than plumbing (as a skill) is a solution to supplying water in your home..
The point — Coding in itself is not a solution.
Where the hell have I been?
I always the “sorry I haven’t posted a blog in a while” posts, but this is one. This blog is largely dedicated to iOS development bits that come across, and in short I haven’t been doing a whole lot of iOS lately.
I’ve been spending my time working with Drupal to craft web services for Mindgrub’s ongoing project. It feels odd to be back in the PHP world again and especially strange to be working on Drupal. In light of what I’ve been working with lately, I’ve got a couple of things I’m planning to work on for this site soon:
- Wrangling Drupal to expose services for use with iOS, or literally anything else. Drupal is nice, but I find the lack of documentation for what I perceive as very simple things frustrating but it’s very common and very popular. There may certainly come the day when you might be asked to connect to Drupal as part of an iOS development project. I plan to outline creating a content types module in code as well as services to feed your iOS app.
- A practical guide to RestKit. RestKit is in active development, so a lot is changing every day. That makes most of the tutorials on the web a little out of date. I plan to write a guide to using RestKit where you have an existing iOS app with an existing CoreData model in place.
One of my goals for the year was to branch out a bit. I’m not sure that PHP and Drupal are exactly where I wanted to go, but onward nonetheless.
A Lesson In Knowing Your Product
Long ago, in my first year at Mindgrub we were contracted to work on a community site that circled around creating a sense of nostalgia. You could go in and become fans (or something) of things from your 80s childhood. The site details really aren’t important, and I’m not even sure if the site is even still around anymore. Regardless, we were working with other far flung contractors to bring this whole nugget together, and it wasn’t happening. At all.
I remember sitting in weekly conference calls discussing the merit of the PHP site architecture, templating systems, database backends. Tons of nitty gritty details that really had absolutely nothing to do with creating a community site. Phrases like “so when when we’re done the templating system will work just like smarty” were uttered often (clarification: not by us, we were only making some javascript widgets). Usually someone would follow with “then why the fuck aren’t we using smarty?”. I recall this verbatim.
The situation continued to spiral into more and more delays as we trudged along. There eventually was a call between our CEO and theirs where our CEO asked why they’re so focused on software development when what they were trying to build was a community site, not a software system. I imagine the silence was deafening.
It was a bad case of “not invented here” syndrome. Symptoms include burning tons of time and energy on something that quite simply has A) already been done, B) probably better and better tested than you could do it, and C) completely ancillary to your core business.
That conversation came ringing back all to true to me on a recent project. We were looking to add a rich PDF viewer to an app with paging, zooming, and all the other bells and whistles. For a few days I looked on the internet, found some sample code, and toyed with some of the Apple examples for displaying PDFs. I got something that worked, sort of. One stray rotation of the device could throw the whole thing out of whack. I was trying to avoid having to pay for a library that does all these. Then it hit me. The goal of the app was not to display PDFs, it was merely one facet of it. I has already been done, better than I could have done it in the time we had to do it. Displaying PDFs was not the business goal of this application. I was doing nobody any good by continuing to churn on it.
The lesson here is to know what your product is, whether it belongs to you or you’re ultimately helping someone else create theirs. It’s always important to recognize that using a well tested pay-for component might just the thing you need to add the value you were looking for and get everyone back to focusing on what’s really important.
2012 – A look back and a look forward
Another day, another dollar. Another year, another . . . something.
Dunno. I’ve never had much use for resolutions related to an arbitrary day of the year. I tend to see goal setting as an ongoing thing and goals as more of a continual series of milestones rather than a single achievable event. Why new years resolutions anyway? Why not 6-month resolutions? Or monthly resolutions? Monthly resolutions in agile sprints? Maybe I’m onto something . . .
Most of the stuff I put up here is highly technical in nature. Tutorials on how to do this or that in iOS or XCode. I was tempted to go technical on this one too. A rambling list of technologies I’ve worked with. Another xxxKit.framework I intend to plod around with.
Boring. Who cares.
That in itself isn’t really interesting to anyone (not even me really). So in a different direction I’m taking stock of what I’m good at, what I’m not good at, and what I want to be better at on a very general level. I think these could apply to anyone working as developer whether working on an indie project (as many people reading iDevBlogADay probably are) or working on client work (as I do).
Things I’m Good At:
Watching the details – It came to me in an epiphany this year. Strangely. I am a detail oriented person. I was never the kid with a clean room. I never meticulously organized my closet by color. I never had the border-line OCD, must-organize-everything kind of personality. I still don’t. On some level I separate ordinary details from Details That Matter.
At any rate, I have a penchant for the details when it comes to my work. I like this. I love this. I used to be envious of the detail oriented folk. I’m pleased to count myself among them in some regard. I think this is necessary for people who work as developers. Your job is detail oriented. “The computer will only do exactly what you tell it”, my dad used to say. To a fault. I take pride in the craftsmanship of my work. I always have. 2012 will be no different.
Making a plan – 2012 was one of my first forays in developing a real, honest-to-god software engineering plan. I thought I’d nailed it. Turns out I was about 75% of the way there (the gaps really showed up during development). Regardless the parts that were planned well went off without much of a hitch and came in under-time against the project plan. This is something I want to expand upon in 2012. You’d be amazed what you can figure out ahead of time before you write one line of code. Every 15 minute interval spent mulling over a problem before you start will save probably hours in development when the same problem inevitably comes up. As mine and Mindgrub’s projects grow ever larger this will become increasingly more important.
Things I Suck At (and want to improve upon):
Automating the mundane – Shame on me as a developer, but there’s a lot of things for which I don’t have automation in place. Simple stuff. Dumb stuff. Stupid stuff I still do manually like pushing a build to test flight or setting up a UITableView. I think there’s a couple reasons I haven’t delved into this more.
- Time is not always on my side, in that the pressure to just get the client work out the door is high to where I don’t think I’ll have time to find/write a script or an automator action or make an XCode template. Usually by the time I notice that I should have automated it I’m already 75% done with the task.
- Fear of the tools – What if automator jacks the upload to testflight? What if the deployment script fails? Dumb fear. Paranoia. I need to get over this one.
- Lack of knowledge – In no way can I count myself as a bash guru. I couldn’t write a Perl script to save my life. Granted automator is a huge help here. In some ways you can put this under “fear of the tools”
Not sure if there’s an easy solution here. First would be to learn the tools: automator, a little bash. I think I’ll leave Perl until 2013. I also have a mind to make a slew of Xcode templates to use with my development team as it always seems there’s a bunch of things we have to add to any UIViewController. Third for me is to try out tools and scripts that get posted to various places like HackerNews and Twitter, see what other folks are doing and try to adopt them into my and my team’s workflow.
Branch Out – I’ve been working with iOS almost exclusively in 2011. It’s great and I love it but I’ve been feeling the need to branch out lately. I believe it’s important especially in the current job market to be versatile as a developer. Learning new programming languages will make you better at whichever language you use everyday. Learning new frameworks will make you think differently about the frameworks you already use. And if you don’t learn anything new, technology will pass you by. For 2012 I want to get a release of a cocoa app. While it’s still objective-c, there’s a lot of nuanced differences between the two. I’ve got a couple of ideas rattling around, just gotta get up and get going on one.
Making every moment count – I feel like I need a little more get up and go in my life. Not that I’m lazy. Far from it. But I want to make more of my free time that I have. That doesn’t necessarily mean more work or side projects but more about getting the feeling that I’m getting most out of every minute. This year I want to work on paring down distractions and focus more on important things.
So, maybe this process was a little more cathartic than I thought looking at the tone of the post from the top to the bottom. At any rate I want to wish those few regular readers and folks from iDevBlogADay a great new year. Happy Coding!
Mindgrub, the company I work for, was featured in this Baltimore Sun article today. Check it out!
Pat Zearfoss 