Software Developer / Engineer. What’s the difference?

10 Jun

Recently I was asked “What’s the difference between a software developer and a software engineer?”

The answer? Well it depends on who you ask. So after a little thought here is what I consider each one to be. It is by no means meant as a true definition, just a way I’ve categorized myself over the years.

First I’m going to expand the question a little bit beyond just the two titles “Software Developer” and “Software Engineer”, I’m also going to add in “Coder” and “Programmer”. Again, this is just how I categorize them, others will most certainly give different answers.

A person who can read some code, make changes, and to some degree understand how those changes affect the output. Back in the 90’s I used a sprite animation library called SpriteWorld. I didn’t really understand how it worked at first, but I could alter some code and change the sprites appearances, the layout of a tile-map, background images, etc. Notably, I wasn’t capable of writing a whole game myself.

Programmer: A person who writes code and understands it well enough to build a basic set of functionality. After working with SpriteWorld and other graphics libraries (GraphicsBuffers, QuickDraw) for awhile, I understood enough to write my own graphics routines (blitters). I was far from a graphics expert, but I knew the ins and outs of blitting (copying, masking, and altering bits for graphics). At this point I was capable of writing a part of a program, or a demo. But still unable to build a fully featured app.

Software Developer: A person capable of building simple programs. At this level you understand nearly all code you look at, at least to some large degree. Even in languages your not as familiar with. You are fully capable of making a multi-screen app and, when necessary, can debug the app when problems arise (they surely will). I wrote parts of games in the 90’s but I didn’t publish my first full game (Consumed) until 2008.

Software Engineer: A highly proficient Software Developer that is capable of managing a complex system. A person who is not only able to build a fully functioning app but is experienced enough to know how to build it in a way that is easy to refactor, self documenting, and as a result easier to debug. They know that consideration and forethought on the front end can save days of work and headaches down the road. They devote themselves not to making the cleverest code, but to making their code obvious. They know the best piece of code is the one you never have to write.

I’ve progressed through these stages in my career. If I’m being honest with myself, today I would place myself in the software developer camp. I’ve shipped multiple apps, and I support them. I can understand most of the code I read, even in languages I’m unfamiliar with. Over the past few years I’ve learned a lot about software architecture. These days I’m considering things like, object ownership, immutability, unit testing, cache invalidation, documentation, infrastructure, error handling, and so on.I learn so much every year, month, day, that I wish I’d learned sooner. I constantly wish I knew then what I know now. But that’s likely a large part of what keeps me programming. The fact that there is always something new to learn just around the corner has kept me coming back for twenty years and I expect it’ll keep me coming back for at least twenty more.

What am I? I’m a student of code.

Moving to WordPress

10 Jun

I moved ShiftyBit over to GitHub pages last fall. While it’s nice, it had one major shortcoming for me. I didn’t have an easy method to make a post.

My method usually involved writing a post in markdown, previewing it, committing it in git and then pushing it out to GitHub. Worst of all, I had no way to post from my iPhone or iPad. When I’m at my laptop I’m usually working so I don’t think about posting then. I usually think about things I want to post while waiting around town or laying in bed before I go to sleep.

What I really wanted was a simple way to post whenever I wanted to, from wherever I wanted. Hence, I’ve moved Shifty Bit to my own server running WordPress. So hopefully, with this lower barrier, I’ll be posting a lot more here. Like say, at least once a month ;)

::fingers crossed::


7 Nov

Earlier this year I noticed something that had been bothering me for awhile. I had more than a few apps in the store; seven of my own, plus a couple for contracts. While no single one of them was taking a lot of time, the aggregate effect of them all left me drained and unable to support any of them as fully as they should be. Some didn’t even support the iPhone 5’s screen size (ouch). It was time to cut some weight.

I’m very fortunate in that my day job pays well for my area’s cost of living. Because of which I don’t have to rely on income from my apps. I looked at this as an opportunity to focus less on trying to make a profit and more on trying to hone my skills.

With that clearly in mind I decided it was time I focused on making the best versions possible of just two or three apps rather than spreading my time and attention across many.

Choosing to remove apps from the store and deciding which ones to keep, especially apps that don’t generate much money (0’Clock literally makes a couple of bucks a month), wasn’t an easy decision.

Ultimately I decided on keeping three:

  • Consumed – as my first iPhone game it’s near to my heart, and my friends and I still play it quite a bit.
  • 0’Clock – a binary clock I made while my wife was learning binary in college. She in turn bought me a real one for Xmas which sits on my desk at work. It requires little effort to do what it’s intended to do, so it’s a good app to cut my teeth on new technology, like Swift.
  • Fit to Fight – an Air Force physical training test calculator that, I’m proud to say, is used by thousands of United States Airmen worldwide.

Just because you can build something, doesn’t mean you should. I’m learning this the hard way. But I’m very optimistic about the future of these apps and what I will learn.

Dispatching your work

2 Nov

Grand Central Dispatch is an awesome technology. There is a ton of stuff in GCD we could talk about, but I’m going to pick one specific part to talk about today.

Dispatch Groups. Apple defines dispatch groups as “a way to monitor a set of block objects for completion. (You can monitor the blocks synchronously or asynchronously depending on your needs.) Groups provide a useful synchronization mechanism for code that depends on the completion of other tasks.”

But what does that really mean to you? Well say for example you want to run some tasks on a background thread and then execute some code when all the background tasks have finished. You could try and use flags to track the state of all the tasks or maybe setup a counter system to track their status and then execute your completion code when all the tasks have finished. But wait, smell that? That’s code smell. You know there’s a better way, and your right. Your so smart.

Dispatch groups provide a convenient way of tracking tasks and can notify you when the tasks have been completed. A dispatch group keeps a counter of active tasks and when the count drops to zero it can call a designated block.

Heres a quick example.

// Create a dispatch group
dispatch_group_t group = dispatch_group_create();

// cycle through dispatching some background tasks
for(int i = 0; i < 10; i++)
	// increment the group's task counter
	// start a background task
		// do some work on a background thread
		// decrement the group's task counter

// set a block for the dispatch group to call when the group's counter gets to zero
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
	// all our tasks have finished

Mike Ash on Swift

28 Oct

Mike Ash had a great post on Swift back in June – Friday Q&A 2014-06-20: Interesting Swift Features. It’s worth a read. Really helped me wrap my head around some new (to me) concepts in Swift like Optionals and Generics. While your there be sure to check out the rest of his site. All of his Friday Q&A’s are great.


27 Oct

Over the past week or two I’ve found myself thinking about blogging but not actually taking the time to write anything. It’s not that I don’t care, but that I don’t care enough to get it through the blogjam of a system I currently have. If I want to post anything I currently have to do so from my Mac.

The process goes something like this:

  1. Copy an old post
  2. Edit the post (usually in TextMate)
  3. Check my use of markdown (I’m still a novice when it comes to markdown syntax, but I do like it)
  4. Save and Commit
  5. Ask myself why I don’t have a better solution

It’s not that this is really bad, but it takes time, thought and care. I have to be at my Mac for one thing. That’s a huge barrier considering most of the time I think about writing is when I’m away from my Mac. When I’m at my Mac I’d rather be programming. I’ve tried a few GitHub iPhone apps but most either are broken (won’t sync correctly) or lack simple text editing features. What I really want is a simple markdown editor with spell checking that will sync with GitHub and that has Mac, iPad, and iPhone versions. If I find that great, but I’m increasingly starting to think I might have to build it myself.

Don’t reinvent the wheel

16 Oct

Many Cocoa developers haven’t worked a lot with web services. But these days if your working on an iPhone app it’s highly likely you’re touching a network, either to access a full API or maybe just fetch some images to populate a table view. When fetching data from a web service one of the first thoughts early on is (or at least should be) about performance. Caching is a great way to get big performance gains, not only in speed but also in reduced battery consumption and decreased network usage. So, naturally you might think you should some form of cache controller class maybe using NSCache for in memory and perhaps a SQL database for persistent storage. But don’t be to quick to chisel that wheel out of the stone.

Luckily if your using NSURLSession (and you really should be) you’re likely getting this for free and you don’t even realize it. NSURLSession by default uses a shared NSURLCache (each app gets it’s own) to cache responses. This means when you make a request for something like some JSON or an image the response is cached (in memory and / or to disk). So the cache will be used for any requests you make to the same URL later. Well, technically the cache may be used. It depends on the http cache control headers set in the response. So it’s important to understand what cache control headers are set for your end point and how they can affect when / how long your cache is valid for. See HTTP Header Field Definitions for more info on this.

On a final note. You should validate you’re cache. I don’t mean in some kind of checksum sense. I mean just verifying that it’s actually performing as expected. The NSURLCache uses a SQL database that lives in /Library/Caches/. You should take a look at that cache and verify that your intended responses are being cached. Depending on your response sizes and how much data you want to cache you may need to setup a larger cache than the default shared cache.

The MacTech archives

15 Oct

MacTech was my favorite magazine back in the 90’s. In the dark ages before the web we had to use paper books, magazines, and stone tablets to learn things. Every time I opened a new issue of MacTech I got a chance to learn a little more about Mac development. Turns out MacTech has an awesome article archive! Take a trip down memory lane and enjoy some great Mac development articles of yesteryear.

MacTech Archives

Hello World

14 Oct
ShiftyBit has been pulled from the ashes and is living again on GitHub pages.