Archive for the ‘General’ Category

You Down With OPC? (Yeah, you know me!)

Thursday, January 5th, 2017

Maybe I’m stereotyping, but something tells me the majority of developers who might be reading this are either too young or not cool enough to catch the reference to the 1991 hip-hop anthem from Naughty By Nature.

I’ll spare you my attempt at retooling the lyrics with something witty to match my message.


5 1/2 years ago I wrote about my search for “The Next Platform”. Based on the rumors of the day, I thought there was a pretty good chance that said platform would be a television created by Apple, that would run apps and open the world to whole new genres of interactive experiences.

Well… a year and a half ago Apple released a new version of the Apple TV, a set top box that connects to existing televisions and does support apps. But it wasn’t exactly what I was expecting. It didn’t allow developers to utilize what I’ve come to believe is the only practical path for a small-time developer to strike it big: OPC.




This isn’t a new concept.

What preceded the iPhone? The iPod / iTunes. Did Apple produce any of the music that its device could play, or, later, when there became the iTunes Music Store, did Apple produce any of the music sold there?

What company accounts for a full third of (US) internet traffic? Netflix. Until relatively recently, did Netflix produce any of the content they were sell… renting?

What company is most responsible for the death of many brick and mortar stores in favor of online shopping? Amazon. Have you ever bought a product that was manufactured by Amazon? (Perhaps a few of you have, but not the vast majority of their customers.)

Okay, those are the big guys. What about on a smaller scale?

Are you on Facebook?

Have you seen, or taken, one of the many quizzes like:

“Which Marvel superhero are you?”

“Which Harry Potter character are you?”

“How many of these ‘80s songs can you name from the lyrics?”

“How many of these movies can you identify from one picture?”

It’s not Marvel, or the music companies or movie studios who make those quizzes.

Some much smaller company / developer is utilizing Other People’s Content to create new experiences for millions of people to consume, and for them to make money from.

So, if you’re a small-time developer that doesn’t own the rights to such content, what are you to do?

Well, you can try your hand at developing an original game, for which you will have to develop new content, in the hopes that, amongst the thousands of other games already out there, yours will be a hit. (Some developers utilize Other People’s Content in this arena as well, cloning existing popular games. Personal experience has shown me that this may result in a Cease and Desist order.)

Otherwise, your best bet is to figure out how to use Other People’s Content, legally, in a way that adds value to that existing content.

One friend of mine has done very well writing software to utilize content created by other companies’ personal weather stations.

Another friend did very well many years back with Yahoo chatroom filtering software.

I have my own ideas about what Other People’s Content I can use to create a new(ish) market niche.

Perhaps it’s time you got down with OPC.

(Don’t) Interface Different

Thursday, October 15th, 2015

Our biggest UI constraints aren’t our tools.

I was just riding with someone whose name shall be withheld to protect the guilty. We were in her new Prius, upgraded from an earlier model. She tried to turn on the air conditioning, (it’s mid-October in Phoenix and A/C is still very much a necessity,) but she couldn’t get it to work the way she wanted it to.

“Is this broken already?!?” And she angrily pushed a bunch of buttons until it did something close to what she wanted.

In truth, the air conditioning is working just fine. More importantly for this discussion, it works AS DESIGNED.

The problem is, the climate controls in her newer model work differently than the ones from her previous model, and she had no patience to figure out those differences.

This interaction is not an anomaly. Not just as a software developer, but as a user, I’ve seen people routinely complain about how a piece of software (doesn’t) works.

This imposes two distinct sets of constraints on us as software designers.

First, we are constrained by user expectations set by their history of use of the platform and other software on it. In an action dialog box or alert on your platform of choice, is “Cancel” the button on the left or on the right? If you don’t know and create such a dialog / alert with it reversed from the norm, or worse yet, you have a personal belief that the usual placement is wrong and intentionally reverse it, you’ve created a situation that’s going to irritate a bunch of your users and cause them to think less of your software. Enough such annoyances and they’ll stop using it entirely.

Second, we are constrained by our own interface decisions. Have you figured out a better way to organize your interface for greater productivity? Do you already have a version of your software out in the wild? You might want to reconsider your “new and improved” interface design. Just like my… driving companion, if your existing users expect things to be set up a certain way, and you change it on them, no matter how superior your new design is, your existing users may see it as broken, or at least bothersome. They may not stick around long enough to adapt to your changes.

This leads to one important conclusion.

I’ve seen others recommend to developers that the most important thing is to get a first, functional version of your app out into the world, and then to refine it later.

I’m going to have to vehemently disagree.

Have you seen the stats on the percentage of users who abandon a mobile app after three sessions or less? They’re staggering. You really don’t get a second chance to make a (good) first impression. In the world of software, you may not get a second chance to make ANY impression.

So make sure you get the interface right the first time through. Follow conventions. Adhere to standards. Make workflows function in as few clicks / taps as possible. Reign in your desire to “Interface Different”.

Are you a Software Architect?

Tuesday, July 15th, 2014

Four years ago I wrote a piece entitled, “What makes a Software Engineer ‘Senior’?” After 15 years in the business, it was still a point of curiosity for me, for a number of reasons. I achieved the official title of “Senior Software Engineer” for the first time at age 24, 1 year into my first official programming job, having no formal training or education in the field, a totally self-taught hobbyist programmer. It was certainly a title I hadn’t earned and didn’t really deserve. It was more a matter of protocol.

Nowadays my nagging question is aimed at a higher target.

What defines a “Software Architect”?

For many of us, this is the Holy Grail of titles. Most companies don’t have long career paths for software engineers that don’t involve getting sucked into management. So “Software Architect” is often the highest title that can be obtained short of something that fits under the management umbrella. And not just a title, the role itself generally affords the holder a higher level of respect, both within the development organization and from other non-technical segments of the larger organization. It affords the holder the prized ability to only partake in the fun, most enjoyable parts of development, designing systems and coding the most interesting components, leaving the mundane aspects of the application, including the dreaded last 10 percent, to engineers of lesser standing. And finally, and perhaps most importantly, it places the holder in the highest salary range available to technical staff.

Because of the supposed significance of this title, and the relatively few such positions available across the industry, very few software engineers ever attain it. At the most formal company I ever worked for, the highest technical title required traveling cross-country to corporate headquarters to present in front of an esteemed group of reviewers, including the company founders, in hopes of being bestowed with the title and the commensurate benefits that accompanied it.

But unlike my question about the definition of a “Senior Software Engineer”, for this question I think I have a much more definitive answer:


We’re all software architects.


“Senior” is something of an abstract term. It has no concrete meaning. In a startup full of fresh college graduates, the 5 year veteran is most certainly “senior”. But in a 100 year old company with a 20 year old development organization, with engineers averaging 12 years of seniority and over 40 years of age, the 5 year “veteran”, 7 years removed from college and 29 years old, is likely not considered “senior” by anyone else in the organization.

But “architect” is much more of a concrete term. A software architect designs and builds software architectures.

Anyone who has built an application from scratch that does much more than “Hello World”, especially an application that requires user input, and especially an application written without the benefit of an application framework, has designed and implemented a software architecture.

Anyone who has written a game without the use of a canned game-building framework has designed and built a software architecture.

Anyone who has developed an event-driven application has designed and built a software architecture.

It is impossible to build a complete application that deals with data, input by a user or retrieved from a remote source, without instituting an architecture to deal with the acquisition and processing of that data.

Of course, not all architectures are equal. And thus, not all architects are equal. To put it in terms of the more traditional type of “architect”, one might be able to design and build a dog house or a shed, but that doesn’t mean you can design and build a mansion.

So we’re all architects. The real question is, how good of an architect are you? THAT, is a subjective assessment much more open to individual interpretation.

So don’t ever be shy about considering yourself, and referring to yourself, as a software architect. You ARE one, most assuredly. If you find yourself feeling uneasy about the label, it is likely because you know you’re not as good of a software architect as you could, or should be.


A Different Type of Optimization

Tuesday, December 31st, 2013

For years I’ve heard the mantra from Apple engineers of not optimizing prematurely, because you never know where your bottlenecks actually are until you profile the running code.

But that’s only one type of optimization.

I, for instance, always optimize for project size.

Expand one of my projects and you’re unlikely to find more than 30 or so class files (counting header and implementation files as one.) Yes, it makes for bigger individual files, but it also makes for a much more easily digestible project tree, and, more importantly, it makes for MUCH less jumping around between files when debugging some complex process.

Over the years I’ve dealt with many applications that send http requests and receive responses. The first thing I do when I inherit one of these projects is to expand the entire project tree to see just what I’m dealing with. Often I find a project consisting of literally hundreds of files, many only a few lines long. One or more class files for every single business object, specialized classes for abstract concepts, multiple classes for implementing a single process, etc…


It has not been unusual for me to see a process flow something like this:


User does something that requires calling a web service.

Method 1 in Class A creates a new request object and passes it to Method 2 in Class B.

Method 2 in Class B calls Method 3 in Class B to get info with which to populate the message header.

Method 2 in Class B calls Method 4 in Class C to get the body info for the request.

Method 2 in Class B passes the request to Method 3 in Class D to format the request.

Method 3 in Class D calls Method 5 in Class E to Sign the request.

Method 3 in Class D calls Method 6 in Class E to encode the request.

Method 3 in Class D passes the request to Method 6 in Class F for sending.


So we have 6 methods in 6 classes just to send out an http request.

Then there’s the response…


Method 1 in Class A gets the response object.

Method 1 in Class A passes the response to Method 2 in Class B to parse.

Method 2 in Class B calls Method 3 in Class C to parse the header.

Method 2 in Class B calls Method 4 in Class C to parse the body.

Method 2 in Class B creates an instance of (business object) Class D, initializing it with the body of the response.

Method 2 in Class B passes the instance of Class D to Method 5 in Class E, which is the final recipient of the result.


So we have 5 methods in 5 classes to handle the result of the http request.

All total, that’s 11 methods in 11 Classes to handle an http request/response. Well… up to 11 Classes, as there could be overlap in classes between the send and receive processes.

And this is just the norm. I’ve seen some projects which easily double the number of methods and classes touched in implementing this request/response.

Now, let’s say you need to trace a request/response from start to finish. You’re jumping around to 11 methods in 11 files. If there’s a problem somewhere you’re trying to debug, and you’re in an IDE that keeps a tab open for every file you hit, you now have 11 tabs open for the 11 files you touched while tracing through this process. If bad data is occurring somewhere, you have 11 breakpoints in 11 files to try to find it.

When I have to debug the above, I roll my eyes and breath a sigh of aggravation at the developer who designed it.

Let me compare that to the actual process I use in Snap That! for implementing http request/response:


User does something that requires calling a web service.

Method 1 in Class A creates a new instance of Class B .

Method 1 in Class A calls Method 2 in Class B with the data needed for the request.

Method 2 in Class B creates the http request, formats it and sends it.

Framework Method 1 in Class B receives data and builds response.

Framework Method 2 in Class B sends response back to Method 3 in Class A.

Method 3 in Class A parses the response and uses the results.


So we have 3 methods (not counting the framework methods required to receive and package data) in 2 classes.

Debugging this process? Simple. Simple. Simple.

The usual objection to doing things the way I just outlined is that it results in unmanageably large source files.

Checking the file for the class I use to process http requests, it has 997 lines (and I put brackets on their own lines and use blank lines liberally for visual clarity) to handle 23 distinct web service calls. I don’t find that to be unmanageably large.

Yes, the two processes aren’t exactly equivalent, but basically there are three things I do that limit the amount of jumping between methods and classes in this process:


1) Using one DataManager class that handles all outgoing and incoming data requests and responses.

2) Inlining the code in one method that creates the request, formats the header, formats the body and sends the request.

3) Parsing the response into a framework-native dictionary class instance instead of creating instances of custom business object classes for every response.


The moral: separation of concerns, encapsulation and modularity are all fine OO concepts, just don’t overdo it.


In Search Of: The Next Platform

Friday, August 5th, 2011

For many years I’ve thought that the surest route to fame and fortune in the modern world of indie software development was to get ahead of the curve and exploit a new, emerging market before it really caught fire enough to get the attention of the big boys with multi-million dollar R&D budgets. That meant predicting what the next big unheralded  platform would be.

At one time I thought that platform was going to be In-Flight Entertainment Systems, those little screens in the backs of some airplane seats that allowed you to do everything from watch movies to play games to search for restaurants in your destination city. Unfortunately, that endeavor failed to take off, no pun intended, to any significant extent.

Next I thought that games, especially casual games, would be the big thing on Linux, which was supposed to take off as a mainstream desktop OS. But then Linux never managed to get that desktop foothold. And regardless, others had started placing bets on that market much sooner than I ever thought they would anyway.

I’m ashamed to admit that the two new platforms that really DID take off, and which I was perfectly positioned to take early advantage of as a long-time Mac developer, I completely missed the early adopter boat on. When the iPhone was opened up to third party development, I thought, “so what?” I never imagined that it would become the Next Big Thing and that simple apps that you could write in a week could make a million dollars. So you would think that I would have learned my lesson in betting against Appl… Steve Jobs. Yet, when the iPad was announced, my response was, “niche product that will never amount to much.” Oops.

So now I know never to bet against Apple/Steve again. And this means that I’m now preparing for the possibility that the next big platform is on the horizon.

Rumors are again circulating that Apple is preparing to release its own line of HDTVsIF this happens and IF such a device can run third party apps like the iPod/iPhone and iPad can, then maybe this is the Next Big Thing that I’ve been waiting years for.

Guess it’s time to start figuring out what kind of television apps I can write.


If an Application is a painting, do you, as a programmer, want to paint a picture on a blank canvas, or assemble a picture from a jigsaw puzzle?

Thursday, June 2nd, 2011

As the years go by in this profession, more and more I see an expectation that professional software developers will utilize any and every framework or library available to accomplish various programming tasks.

The truth is, there isn’t very much code to write that hasn’t already been written a hundred times over. Every general programming “problem” has been solved, and there’s often a generally accepted “best” method to solve any such problem.

However, if you’re in this business because you enjoy the “art” of developing software, then you probably enjoy developing your own solutions to programming problems, even if canned solutions to those problems already exist, and even if the solutions you come up with aren’t necessarily as elegant or optimized as the solutions that already exist.

In other words, lots of us like reinventing the wheel. It’s part of what we enjoy about what we do.

When we’re working on our own independent projects, this isn’t an issue. We’re free to do as we please.

But when we’re taking a paycheck from an employer or charging a client for our time, their ultimate goal is to get the desired finished product, as quickly and cheaply as possible. Our desire to spend extra time developing our own solutions to problems is usually incompatible with their goal.

But there has to be a balance.

Yes, it may be unreasonable to decide you want to write your own xml parser on your employer’s/client’s dime when so many other canned solutions already exist.

However, keeping you engaged, challenged and interested in the project and your work is also a very important factor, for both parties.

So if someone suggests that you use Framework X to make web service calls, library C to process the returned results and open source project N to display the results in a nice, pre-fabricated UI, if that’s the majority of the application’s functionality, then they’re asking you to become a puzzle assembler, a code monkey, a paint-by-numbers “resource” who likely won’t take any joy out of the work you’re doing.

Find the balance. Determine which wheels would be unreasonable for you to reinvent, which wheels you will learn the most from reinventing and which wheels you can bring something new to the table for.

Then have at it!

But most of all, don’t get trapped assembling coding jigsaw puzzles for the rest of your career, which likely won’t be very long if that’s all you’re stuck doing.


Fending off Attacks on Average Joe Software Developers

Thursday, April 14th, 2011

It was a year ago this week that I started this little venture.

Coincidentally, just yesterday I took part in a debate that typified the whole reason I decided to start this blog in the first place.

Be it specific to Cocoa development or more generally applied to the profession of software development, there’s a segment of our profession that only respects those with the utmost of programming skill, or at least those who strive to attain such.

In no field is EVERYONE “elite”. By definition that would be impossible. There will always be those who are “average”. In fact, by definition, the MAJORITY of people in any field will be “average”. But average doesn’t mean “mediocre”, (I just looked it up to be sure.)

A lot, if not most, of the software out there in the wild was developed and is maintained and extended by “average” programmers. These programmers are perfectly capable and competent. And they should be respected, even if they aren’t always striving to be elite, to learn all of the ins and outs of the SDK/platform/language that they’re using; even if they do things in non-standard ways; even if they buck platform conventions by trying to develop software on one platform using conventions and design patterns that they brought over from another platform.

The goal, for most programmers, is to produce a finished, working application.

Users of that application couldn’t care less how it was developed, if it “just works”.

There are programmers out there, hmmm… what did I refer to them as a year ago? Oh, yeah, “Hotshot Superstar Software Engineers“… who desire to have the most pristine, optimized, streamlined code that always uses the most appropriate aspect/feature of the language/SDK in its implementation.

Good for them. More power to them. I don’t begrudge them anything.

But personally, I would MUCH rather release a program that does something unique and is adored by users, but was implemented with code that was ugly, unoptimized and inefficient, than to write the most beautiful, optimized, streamlined, efficient routine to implement a feature 20% faster than anyone else ever has, and have users go, “meh, there’s a dozen other apps out there that do the same thing.”

So while Hotshot Superstar Software Engineers continue to degrade and belittle “average” programmers, I’ll continue to stand up for them, and proudly declare myself as a member of that group.


Wow, some people really, REALLY like Microsoft and Windows!

Sunday, August 29th, 2010

So, over the last two months I changed jobs. Now I work for a shop that does consulting… primarily Windows-based consulting.

I always knew that there were people out there who really did like Microsoft and their technologies. But W-O-W! Being here, I’m absolutely amazed at the degree of Microsoft adoration! I’ll admit that it does turn my stomach just a bit, but I have come to find that, as JavaEE, Apple, Google, Open Office, Facebook and others have become more relevant, Microsoft has become less relevant, and thus I don’t thoroughly despise them as much as I used to.

Besides, this is a really good group of people that I’m working with now. And even better, I get to be an insurgent having a Macbook Pro on the company network and making iOS development contribute more and more to the company bottom line.

Perhaps my selling out is nearing a point of no return…


What makes a Software Engineer “Senior”?

Tuesday, April 13th, 2010

After 15 years of undergoing interviews in this business, one question always haunts me when I’m seeking a new position:

“Do I have the right to call myself a ‘Senior’ Software Engineer?”

The answer may seem obvious:

  • 15 years of professional development experience
  • Major if not sole contribution to numerous shipping applications
  • Numerous independently developed applications for multiple platforms
  • Experience leading in-house and offshore development teams
  • Multiple years of experience in C, Objective C, Java, Visual Basic and, to a lesser extent, C++
  • The title of “Senior Software Engineer” at several companies

But wait, there are good reasons why I still ask the question:

  • I don’t consider myself anywhere close to an expert in any language that I know
  • All of the code I write is written simply, at a novice level, so that anyone who has taken one class in the language can understand it. I don’t use concepts or language features introduced in the “Advanced Topics” sections of programming books. Therefore, I don’t understand those concepts/features when I encounter them in other peoples’ code and I’m fairly lost until I can get my hands on a book to brush up
  • Practically every time I see a macro defined in code I think, “what in the world is that and what does it do?!?” because I never use macros myself
  • I don’t have a particularly good memory, so I find myself referencing documentation to get the correct syntax of or method signature for language features or methods that I’ve used practically every day for years
  • I’m not particularly skilled at using any IDE. I use them for basic editing, compiling and basic debugging. 90% of what most IDEs can do I’m not familiar with and never use
  • I almost never use profiling tools or any of the other very useful development tools outside of the IDE itself
  • I’ve never been particularly diligent at error checking or handling. I rarely use exceptions and never use assertions

So I can’t give a definitive answer to my question. Maybe it boils down to the larger question:

What makes a software engineer “senior”?

I wish I had some great insight into the answer… but I don’t.

When it comes down to it, I do call myself a “senior software engineer,” for a number of reasons.

Time spent in the industry DOES count for something. It’s a reasonable assumption that the more time you’ve spent working in the field, the more problems you’ve had to solve, the more your problem solving skills have matured, and the better equipped you are to overcome future problems in a reasonable time with reasonable solutions.

In a corporate programing environment, managing the personalities of your coworkers is almost as important as managing code. Software engineers are notoriously, and legitimately, criticized for poor social skills. Surviving in the industry long enough to become “senior” likely means that you’re at least adequate at managing the personalities of people with slight social disorders.

If I’m assigned a task to accomplish, I WILL accomplish it. The code I write may not be the most efficient, or use the most relevant features of the language, but it will WORK. And perhaps more importantly, the next programmer who comes after me, even if they’re fresh out of school, will be able to understand it.

My history as a self-taught programmer, I think, makes me more likely to be able to pick up a new language or framework and run with it when the company needs it. Plus, I’m also more likely to be keeping up with new trends and technologies all on my own, because I care about more than just the project I’m working on in my 9 to 5, and often the stuff I work on on the side is more likely to be cutting edge.

So, at the end of the day, a Real Programmer, despite not being a Hotshot Superstar Software Engineer, can nevertheless make a great Senior Software Engineer.

Hopefully the next hiring manager who interviews me will agree, especially if they’ve read this. :-o

“Real Programmer” truisms, rules and maxims

Monday, April 12th, 2010

I’ve been programming for over 20 years.

I’ve been a professional software developer for 15 years.

There are certain things, in that time, that I’ve come to understand, both in terms of how things are, and how things should be.

Hotshot Superstar Software Engineers will probably disagree. But this is a blog by and for Real Programmers, so their opinion doesn’t count.

Without further ado, here’s what I “know”:

1) 90% of Real Programmers use only 10% of their IDE’s features

Over the years, IDEs have gotten more powerful, more flexible… and more complicated. Nowadays they can do everything except write the code for you. Oh wait, they can do that, too. Nevertheless, in my experience, most programmers use their IDE to do three things: edit code, compile code and debug code. Yeah, I know, that’s obvious. No, you’re not getting it. Most programmers don’t use their IDE to profile code. They don’t use it to set watchpoints. They don’t use it to attach to rogue processes. They don’t use it to create and reuse their own code snippets. They don’t use it to automatically refractor code. They don’t use editing features beyond cut/copy/paste. Many of them don’t use it to browse documentation. I even know one who still debugs using “printf” instead of using more modern debugging features. Most don’t even modify the default layout, hotkey or syntax coloring settings.

2) Real Programmers only use about a third of the features of a programming language

Object oriented programming languages are very powerful and very flexible. Most have esoteric features that let programmers accomplish great things with minimal coding. Real Programmers don’t use esoteric language features.

Also, anything listed in the “advanced topics” section of a programming book is probably a feature Real Programmers aren’t going to use and aren’t going to recognize or understand when they come across it in someone else’s code.

3) Hotshot Superstar Software Engineers use advanced features of a language just to show off the fact that they can

Nuff’ said.

4) Programmers working on projects that will have to be maintained by other programmers SHOULDN’T use advanced language features

Unless you’re working on a personal project, odds are you’ll eventually move on and someone else will inherit your code. That someone else might be a Hotshot Superstar Software Engineer who knows more about the language than you do. But odds are it’s going to be a Real Programmer. Don’t be the jerk that makes life harder on your coworkers when you really didn’t need to.

Code that will have to be maintained by other programmers should be written, as much as possible, so that a novice can understand it.

Caveat: you work at a company that’s prone to having random layoffs, (even though the company is financially stable,) or shipping your job offshore. Programming complexity may lead to job security. THAT, I’m never going to argue with. If your company isn’t concerned about protecting your future livelihood, then you don’t need to be worried about protecting the future maintainability of their products.

5) Most software engineers have never actually typed “main(int argc, char *argv[])” (or similar) outside of a classroom setting

A lot of programmers out there came up in the era of modern IDEs. When they want to start a new project, the IDE takes care of certain basic stuff for them, like coding “main()”.

Maybe more importantly, many programmers who took up programming as a career path have never written a complete app of their own, or even started a REAL app of their own. Instead, ever since college they’ve taken jobs working at established companies where all they do is maintain or extend applications that were first created before they even started high school.

6) The best Real Programmers started (and usually continue) programming as a hobby

I know a lot of programmers. If I had to staff my own software company, I would do it strictly with people who started programming as a hobby, and it eventually turned into a career for them. Going to college to study programming wouldn’t mean anything, unless you had still started as a hobbyist. Then it might be worth a bonus point or two. Maybe half a bonus point.

Hobbyist programmers program because we love it. Programmers who are in the business because they graduated high school and some aptitude test told them they would be a good software engineer and software engineering is a lucrative career, are in it for a paycheck.

7) Real Programmers who started as a hobbyist in the 80s programmed on an Apple, TRS-80 or Atari 8 bit computer

I started programming in the 80s, as did a lot of the other programmers I know. Of everyone I know who was “into computers” back then, every single one who owned a Commodore 64 or early IBM PC/PC Jr. DIDN’T end up as a programmer. Most of the people I know who started on a TRS-80 Color Computer or Apple 2 or such, ended up as a professional programmer.

8) Being a “software developer” ONLY implies that one knows how to write code

There are several different designations given to programming jobs: computer programmer, software developer, software engineer, etc… (makes job searches really irritating)

But unless there’s a “Senior” in front of the job title or a number higher than ’2′ after the job title, it doesn’t mean that the person knows how to use an IDE, knows how to use programming/debugging/testing tools, knows the first thing about databases or web technologies, etc…

A “software developer” could be someone who’s done nothing but program command line utilities for Linux in ‘C’ and never even used a modern application framework. And you shouldn’t expect any more than that.

9) When a Real Programmer says they’ve tested their code, all that necessarily means is that they’ve tested for success

A piece of reasonably long code can fail in dozens of ways. Real Programmers program because it’s fun. There’s nothing fun about testing for dozens of potential failure conditions.

However, a good Real Programmer can tell their testers, (the people who are actually paid specifically to test for failure,) exactly where their code is likely to fail and not recover gracefully.

10) Real Programmers like reinventing the wheel

Solving programming problems is fun. That’s why we do it. Very few, if any, problems we face haven’t been faced and solved 1000 times before we encountered them. The generally accepted answer to any programming problem is usually “out there” and easy to find.

But if you want someone to develop an application by piecing together a bunch of standard code fragments, then hire a trained monkey to do it. There’s no fun in that. There’s also no personal development or valuable experience that would be gained by developing your own solution.

Or… wait… is that actually descriptive of Hotshot Superstar Software Engineers?!?

Now I’m confused…