Interesting posts.<p>I'm not especially keen on the title "Software Engineer", though I accept by now that it is deeply entrenched. While the title "Engineer" doesn't carry the same general expectations of specific education and credentials as "Lawyer" or "Physician", it does carry those expectations within more narrow titles - a "Structural Engineer" means something very specific and people do have specific expectations for it. It's a complicated topic, but I'm one of those people who thinks that programming has deeper roots in math than engineering, and I am unsettled by the idea that the PE people would be able to leverage their control over the word "engineering" to gain control over who is allowed to call themselves a "software engineer", and then use this power, through scope creep, to start to restrict the practice rather than just the title. I lean against the idea of formal exams (a "bar" for software). I'm not completely opposed to it, but if it happens, I'd prefer to establish it completely independently of any professional <i>engineering</i> accreditation, since I just don't think computer science, or even the modern practice of writing software, is sufficiently similar to engineering to be considered a subset of the PE exams.<p>Software Developer is fine. I never minded "Programmer", I guess some people feel it's a low status sounding term that focuses too much on writing code rather than the other tasks that are equally or more important to writing good software.<p>Now, that second part there does hint at why job titles and especially (not mentioned in these blog posts) job <i>descriptions</i> ("job cards") can be so essential for software developers. As I've gotten more "senior" in my career, I have found my job card to be an essential line of defense on more than one occasion. There are a lot of people out there who want to put software engineers (I'll revert to the commonly used term here) in a box. They want to see the programmer as the worker who can execute someone else's vision, but they will try to deny the programmer the autonomy and decision making authority that comes with a more senior role.<p>There is, of course, a limit to autonomy on all sides, and there are grey areas between technical and business decisions, but it helps enormously to have a document that lists what it is you were hired to do. Job cards for more senior technical workers often have phrases like "establishes system architecture", "evaluates and determines technology choices", or even more deliberately ambiguous things like "works with business units to align business goals with technology" (where autonomy can clearly overlap). But it makes it clear - the technical side engages collaboratively with the business unit, but it isn't simply there to execute whatever it is the business unit tells it to do.<p>People often don't like job cards because they imagine the phrase "that's not in my job card." However, I've found that's not really the problem, at least for me. I'm more that happy to do things that aren't in my job card if that's what needs to be done. But I have found myself in a position where I'm saying "that <i>is</i> in my job card." A business leader may want to take a decision that at least (according to the organization) requires my input, and tell me how it is going to be. If this escalates, it's very useful to have a signed, sealed and delivered document establishing your role in the organization.