What’s in a Job Title

One of the most frequently asked for attributes on a credit or job application is Job Title. As an independent business owner I have answered this question in multiple ways:

  • Programmer
  • Software Developer
  • Software Engineer
  • Architect
  • CTO
  • Coder
  • President
  • Jedi Master
  • Etc…

The scary thing about this is there is no real way for a potential employer,  banker or client to certify what I say is legit. This is a fundamental issue with our industry. There is no way to verify whether a person is a quality software engineer or simply a charlatan. And for the record there are more of the latter than the former.

For the most part programmers like to think of software development as engineering. We like to compare ourselves to engineers with a capital E, construction managers, manufacturing process managers, etc. But do we really practice engineering ? What is the bar for calling yourself a software engineer?

I know for a fact that if I need an expert licensed plumber, electrician or ironworker I can take myself down to the local union hall and find someone that has gone from apprentice to journeyman over the course of many years.  And thanks to my friend Eric Anderson I learned that there is such a thing as a Professional Engineer. Here’s the list of requirements for Professional Engineers as taken from the Wikipedia

  1. Graduate with a degree from an accredited four-year university program in engineering.
  2. Complete a standard Fundamentals of Engineering (FE) written examination, which tests applicants on breadth of understanding of basic engineering principles, and optionally some elements of an engineering specialty. Completion of the first two steps typically qualifies for certification in the U.S. as an Engineer-In-Training (EIT), sometimes also called an Engineer Intern (EI).[5]
  3. Accumulate a certain amount of engineering experience under the supervision of a P.E. In most states the requirement is four years, but in others the requirement is lower.
  4. Complete a written Principles and Practice in Engineering (‘PE’) examination, testing the applicant’s knowledge and skills in a chosen engineering discipline (mechanical, electrical, civil, for example), as well as engineering ethics.

For software engineering there is no similar accreditation process. Any Mort i.e (NOOB) with $500.00 and the ability to hit the keyboard with his/her forehead  can become a software engineer overnight.  "Yesterday I couldn’t spell it. Now I are one". This has got to stop.

A few weeks ago I came across a commentary made by my friend Billy Hollis in Visual Studio Magazine Commentary: Is Agile Rock or Disco. In this commentary Billy mentions the following:

The Patterns and Practices group at Microsoft is heavily into agile development. Don Smith is in that group, and, at a conference last May, he said, "It’s hard to do agile without really good developers." I’ve heard variations of the same thing said from others.

But not all developers are that good. Therefore, if Don is right, then agile isn’t for everyone.

The second statement is the core problem we face. It raises the white flag of surrender to all the half ass coders out there. Why shouldn’t we all strive to be good developers? Why is average acceptable? What does the author propose we do with the average programmer?

Because programmers are less than good (LTG) does he propose we have no process whatsoever? It’s because of these LTG developers we need agile practices more not less. I want to point out something carefully at this point. It’s agile practices… not agile! There is no push button template  you can use and whoosh you are an agile coder or development shop. Nope agile is a set of principles and practices.

Adopting agile principles is not quick or easy. It is a lifetime commitment that takes lots of study, practice, mentoring, and continuous education and improvement. There are lots of new terms, concepts and practices to examine, consider and implement. Every company and situation is different and there are a number of useful practices to adopt.

Agile Adoption

In the last year we have moves very heavily from our old RAD way of doing development to a more agile one.  Our goal in this process was to change how we design and develop software in a quality manner. These are the tools and practices we have adopted.

Shared State Source Control

The first practice we adopted was changing from a pessimistic style of source code control into a shared state source code control system. It made no sense to limit a source code file to a single developer (the default behavior of Visual Sourcesafe). We moved to Subversion. Subversion is an industry standard source code control system that’s default behavior is multiple developers working on the same files and merging conflicts. 

Automated Builds

Another principle of agile we have adopted is that of automated builds. Another terms for this is Continuous Integration.  Whenever source code is committed to our repository an automated build fires off, checks out all the code, compiles it and runs a suite of automated tests.  Our goal is to find whether or not our code is in a Red (bad) state or Green (good) state. 

Test Driven Development and Design

Of all practices in agile I find this one to provide the most value.  Any software you build should be accompanied by a suite of tests to verify its long term quality and  integrity.  The ultimate goal of TDD is a good design.  While test driven development does not insure a good design your chances are better that your designs are more sound if they can be tested in an automated way.

I had a conversation with Scott Bellware and Chad Myers last night. We were discussing testing nomenclatures and Chad Developed this list of test types:

  • Proofs  – Code performs as expected.
  • Examples of Client Access (API testing) – API Proving with tests.
  • Specification (BDD) – Documenting intent.
  • Contract Enforcement/Change Confidence – Regression testing

As you can see these nomenclatures provide you with a confidence that your code will work as expected, has its intent documented and allows for long term changeability inherent in all software development.

Pair Programming and Mentoring

Union plumbers and electricians go through extensive apprenticeships before they are accepted  as journeymen. Software engineers should adopt similar practices. Pair programming facilitates knowledge transfer from master to apprentice,  mentor to student and in lots of cases from student to mentor. In the last year I have spent a lot of time discussing these practices with a number of different people I consider my mentors. My mentor list includes Scott Bellware, Jeremy Miller, Chad Myers, Jeffery Palermo and numerous others. These practices are not always obvious or simple so it is a good idea to have a network of mentors to rely on.

Adoption of Dependency Patterns

One aspect of building testable systems is reduction of  development friction. One way to introduce friction is to tightly couple processes together by allowing them to instantiate there own resources internally.  It may seem strange  but information hiding is not necessarily a good practice in the agile space. The concept behind dependency injection is this: if a component or method has a dependency on another class, then  that dependency should be passed (injected) into the consumer.  This give you untold flexibility when it  comes to configuring and reconfiguring your systems.

Daily Stand Ups

In agile development a common set of practices revolve around daily developer meetings also known as stand ups. Every day developers stand in a circle, stands at there desks or in the hallway and talk about two items:  what the did yesterday and what they plan on doing today. This  has the benefit of keeping all  developers in the loop and facilitating communication.

Small Iterations

We all know that estimating timelines on most software projects is a fools errand.  Software estimates follow share a common trait with metrological predictions the shorter the span or time the more accurate the estimate is likely to be. Agile practices acknowledge this as a core principle.  Your applications should be developed in short sprints.  At the end of each sprint there should be "show and tell" for the client that demonstrates the deliverables for that sprint. After the sprint and accompanying demo the next sprint should be planned. And its rinse lather repeat from there.


While not definitive this list is a good start to moving you or your development team closer to being professional software engineers. When you are evaluating a client, consultancy or even a potential employer consider the practices discussed in the list. 

Do you think your a great coder or do you think your development shop is top notch? I challenge you to prove it. Can you develop quality software that stands the test of time ? Do you have software you can modify with a high level of confidence that your modifications don’t introduce software regressions? Can you repeat and improve on your successes? Do you have the processes in place that make this a possibility? When you can answer in the affirmative to some or all  of these questions you are closer to being a true software engineering shop.

This entry was posted in Agile, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

16 Responses to What’s in a Job Title

  1. Bauer says:

    The most important thing is to keep asking yourself these questions cause customers can’t do it for you.

  2. cody says:

    “Why shouldn’t we all strive to be good developers? Why is average acceptable?”

    This one point stuck out for me…the average developer could be a good developer. By definition if everyone is or became a ‘good’ developer they would be still be average.


  3. “Any Mort i.e (NOOB)”

    Actually, Mort is short for Mortal… which is an euphemism for “regular programmer”… which in turn represents 99% of all programmers out there.

    “This has got to stop.”

    Oh yea, I’m sure you incompetent programmers (hey, you started it :P) would love for us to be legally forbidden from competing for your jobs. No, you may not hire him, he doesn’t have a Carnegie-Mellon PhD! (Aka he’s an ugly furriner.)

    Good thing the architecture astronauts don’t yet dictate who can be a programmer… or we’d be in the same mess the medical profession is. (Boss: we need an application to monitor this folder and copy and new files to this other folder. Legal: where, we can hire Peter Norvig in a couple of years, he has a couple of months free on his schedule and he’s only charging a billion dollars an hour. Yep, Nirvana.)

  4. Jim Cooper says:

    I’d like to take umbrage at this remark:

    “The concept behind dependency injection is this: if a component or method has a dependency on another class, then that dependency should be passed (injected) into the consumer. This give you untold flexibility when it comes to configuring and reconfiguring your systems.”

    You should NOT always pass dependencies. In fact, there is little point doing it unless there is a need for the “flexibility” (I don’t really like your use of that word either) it gives.

    All DI does is move a factory of some sort from within a class to outside it. If you don’t have a factory, then you don’t need DI – it is perfectly OK for a class to construct instances of other classes internally.

    When it MIGHT be a good idea is those times a factory is used instead of a constructor call. IME this is typically because of configuration options, or to provide mock objects for testing.

    But even then, it depends on the factory. If the factory relies on values external to the class, move it and use DI. Otherwise it is normally better off where it is.

    PS. Just nitpicking, but it’s “their own”, “their desk”, “fool’s errand”, “you’re a great coder”, and “ensure a good design”

  5. Andrew says:

    I find that people are more important than any sort of development philosophy. Put a good (or great) group of developers in a Waterfall shop and they’ll produce better code than an average group using an Agile method.

    So saying that by following Agile “is a good start to moving you or your development team closer to being professional software engineers” is very close minded.

    Also, I find Stand Ups and Scrums tend to get used more as a crutch for bad management/PMs as opposed to adding any real benefit to the development staff. I’ve been on both sides of it (Engineer and Development Manager) and have found them practically useless. Simply communicating effectively works much better.

  6. Josh says:

    I think it is all in the interview.

    1. Get a code sample that is beyond a hello world.
    2. Have them spend a few minutes looking through a code base with one of the perspective teams they may join. Have them ask questions and see if they have passionate responses on how they would do something differently.
    3. Have more than one interview.

    The reason I think it cannot be as simple as certiifying someone to build a bridge or a house is the level of change is way more extreme than the changes made in building a house or a bridge.

    How many people you know ripping out a wall in there kitchen so they can add networking to the stove and fridge :)? The pace of change in most egineering based disciplines take decades to change.

  7. Steve Bohlen says:


    I think that variables in quality will be present in ANY product marketplace; this is to a large degree why there are both YUGOs and PORSCHEs on the road at the same time.

    To try to ensure that these varaiables don’t exist in the marketplace is tilting at windmills to a large degree — I actually think that the marketplace does a pretty good job of washing out the low-quality producers; a significant portion of our work is in cleaning up the messes started by just such people, whether internal staff or outside consultants. I DO wish the world was perfect and these people didn’t exist, but its not and they do so we make the best of the situation.

    I used to practice architecture (real architecture, with buildings) and so I completely understand the desire to try to codify what it means to be a software engineer — but I also understand why that’s a fool’s errand in a field as immature as ours where the body-of-knowledge changes so fast.

    Would that it were not so, but it is. In this environment there is (sadly) room for both the expert developer capable of practicing Agile-ly and the (relatively) unskilled developer incapable of those same practices. This is rather like the fact that both a NASA rocket scientist and a building electrical engineer may both be ‘Registered Electrical Engineers’ but you would be a fool to suggest that they are interchangable with each other :)

  8. Steve (Smith),

    In the absence of choice, do you care how your vendors make the software that you use? Do the qualities matter to you or do you resign yourself to what you get?

  9. Glen: I do understand that one of the goals of pairing is to help to create better code, tests and ultimately better design. I guess I see paring on a higher level. Even if the two coders are top notch they will still mentor each other. In my example I used the menotr-student example. But aren’t we all mentors and students when working with other coders :)

  10. Steve Smith says:

    Different Steve, but to answer your question, I’m ok with vendors doing whatever the hell they feel like to make their software, provided there is choice in the market and I’m free to choose the best option for my needs.

  11. Steve,

    As a consumer of software products, are you as OK with vendors using unskilled labor an often naive management of design and process?

  12. Steve Bohlen says:

    Agile (practice!) *IS* hard — much harder than traditional waterfall processes and as such the bar for successful participation in an agile project *IS* much higher than for many other project types.

    The safety-nets (bug-finding nets, QA/QC processes, etc.) that exist for non-Agile practices are mostly performed by other-than-developers in most cases. The safety nets in place in an Agile project require entirely different skills from your developers. I think the conclusion that ‘Agile is not for everyone’ is completely correct and entirely defensible.

    You don’t staff-up first, then pick a way to manage your work — you decide how you plan to get your work done and THEN you hire for that methodology. If you plan to run your projects in an Agile manner (as I do) then I’m 10000% OK with the fact that this may mean that I need to change my staff load-out. Those people that don’t meet the quality bar shouldn’t be working for me in the first place — they can get jobs in a non-Agile shop somewhere.

    That said, much of getting existing developers to be successful Agile-adopters is about training and mentoring and (as one of your bolded points mentions) this is essential to the professional growth of anyone (developer or otherwise) so we try that first.

    But if we are going to work Agile, then that may mean we lose some people who just cannot hack it. And that’s >>OK<<. If people stop HIRING mediocre developers, there won’t be a market for people with these skills and supply/demand will sort out this problem for us.

    For the time-being, I’m OK if all the mediocre developers can only get jobs at my competition 😀

  13. Glenn Block says:

    Nice article Rod. The one question I have is around what you mentioned on mentoring and pairing. Are you saying that the primary goal of pairing is mentoring? I do see pairing as one means of mentoring, however not a the goal.


  14. Billy Hollis says:

    “Because programmers are less than good (LTG) does he propose we have no process whatsoever?”


  15. In the section on “shared state source control” I think you meant to use the word “practice” rather than “principle” 😉

  16. Great post. No where did you say not to document requirements and not to do any planning. These practices you discuss are what makes Agile work.

Leave a Reply