Justa Software Engineer
Justa Software EngineerI don't wanna be JustaSoftwareEngineer. I wanna be JustaProgrammer. Let people under-estimate me at their peril. Correct code talks, bullshit walks. -- JohnFarrell
(Better titles == more money. Sorry.)
'kin-A-firm. -- RonJeffries
The problem is that engineering and design are different things. 'design' is just planning ahead for what your object will look like. 'engineering' means making absolutely sure that you are right beyond any shadow of a doubt, and staking your career on every decision you make. Bad code will get you fired. Bad engineering will end your career, and possibly get you sued or arrested. Engineers aren't certified like MCSE's, where certification implies the ability to perform a skill - they're certified like doctors and lawyers, where certification implies the understanding of their responsabilities and the fact that their name will be on everything they do. Software engineering is only appropriate as a concept where poor funcionality is physically disastrous. Poor wiring can kill someone. Poor environmental controls can kill someone. Poor construction can kill someone. In the case of factory software controllers, poor firmware can kill someone (hence we have industrial and systems engineers who are very talented at gritty systems programming in C and Ada, but don't know a thing about high level design).
Of course, as software is now handling life-altering financial transactions, software engineering is reasonable as a concept. But confusing the nature of software engineering and software design is a trap. Engineer does _not_ mean designer++. A great engineer may be a poor designer, and vice versa. Engineering describes a concept of thoroughness and dilligence, whereas design describes a concept of organisation and creativity.
Yes, this is just an argument over definitions, but definitions are important when they're tied to concepts like liability and certification.
Personally, I'm a graduate of an engineering program now happily working as a JustaProgrammer, and don't see a thing wrong with that.
Programmers Are Not Professional Engineers?
Unfortunately, calling yourself JustaSoftwareEngineer brings up issues with professional engineers. Semantic arguments aside, unless the person is accredited with a professional engineering designation, engineers will ALWAYS have issues with programmers calling themselves software engineers.
(Does this mean I have to go back to school and finish that BSEE I left behind about 25 years ago? Darn!)
Some universities offer computer software degrees in multiple flavors, perhaps as a choice between the Department of Arts & Sciences and the Department of Engineering. With a computer science degree from an engineering school, getting "professional engineer" accreditation was said to be simply another test.
So, get yourself a professional accreditation as a SoftwareEngineer. In Europe this is only as hard as it should be. There are several charter bodies in various EU countries that will give IT professionals who can demonstrate various competencies some letters including "Eng." after their name. Maybe not competencies that most Wiki folk would aspire to, but that is a different, although interesting, matter. Altho' the main criterion is to demonstrate continuous improvement, thus avoiding the OneYearsExperienceTenTimesSyndrome?.
An interesting question: How many electrical engineers do you know, who have professional accreditation of any sort? It certainly is available, and needed to practice in some disciplines; but many EEs are never accredited by any professional body (beyond a college degree). Where I work (a company which manufactures embedded systems), I can't think of any of the "hardware engineers" (as we call them) who have accreditation. Some of them don't even have college degrees -- they started out as technicians and got promoted to engineering (a career path not likely available today; nowadays the company generally won't hire/promote engineers without degrees).
Yet nobody disputes that EEs are engineers...
I've been working towards this goal all my software career.
In fact, let's come right out with it. If you want to be JustaProgrammer, then you have fear, fear of what it means to be a chartered professional. Florman tells a touching story in one of his books (can't remember which one) about a construction job he was on: the safety inspector comes round and examines various things, then requires all the engineers involved in the building work to tell him their registration numbers with their respective professional bodies.
Now, that kind of responsibility and accountability is part of what I aspire to, when I aspire to being a SoftwareEngineer. I fail to meet that aspiration every day, but I try. Maybe one day our industry will grow up.
And maybe, if we really seriously started calling ourselves engineers, maybe one day we might start behaving like engineers. In the best sense of the word.
And maybe if customers/managers/PowersThatBe stopped treating software like an add-on, and forced design changes to be approved the way building changes are, we could get 6 9's quality -- Pete Hardie
I can understand that. Some of the ugliness that engineering students have to go through (especially the math) is truly frightening to many programmers (even me, and I took math as a second major). We programmers, on the other hand, should have serious issues with engineers who claim that they can program. There are some who can, but the thinking mode is very different and most of the worst code I've ever seen was written by real engineers dabbling in things that they didn't understand.
-- DonaldMcLean
Programmers Think Like Engineers?
In what way is the thinking mode very different? To me, engineering is about solving problems in standard ways wherever possible, and sharing the best of your solutions with the engineering community when you have a new or better solution. Engineers have been using design patterns, peer reviews, standard notations, and rapid prototyping for many decades. Not to mention testing... -- KayJohansen
I have run into too many examples of Electrical Engineers who had taken 1, maybe 2 programming courses in college, who thought that they could write good software - until 'those guys stop calling themselves programmers, I have one less good reason to not call myself a SoftwareEngineer. Everyone who's taken one course that includes a programming language thinks that they are now a programmer, and I am tired of getting tarred with the same brush -- Pete Hardie
Me Too -- I have spent some 20 years learning what I know about software, the learning has slowed down but nowhere near stopped. I recently stepped up to a new level of experience and understanding. I originally studied physics, I have as much reasonable claim to call myself an Electrical Engineer or a Mechanical Engineer as they do to call themselves a Software Engineer. Even if they have dabbled over the years, so have I. I have designed and built electronic and mechanical devices and they work, but I am no EE or Mech E and I know it. It is just a shame that most EE and Mech E don't know they can't code much less design. Now it is possible for a Mech E or an EE to learn to Software Engineer, but I doubt they can do it by reading many fewer books or going to fewer lectures than I did ......
For a counterpoint see TheWayRogerWroteCode.
Job Titles
Title, I don't want no stinkin' title. See JobTitles for my rant. -- JavaSchrod -- DavidLegg? I don't want to be JustaSoftwareEngineer; that implies I'm some sort of sophisticated scientist - I think JustaProgrammer is right as it has more of an arts and crafts feel An engineer isn't a scientist any more than a scientist is an engineer. See ComputerScientist.
The first time I had an impulse to call myself a SoftwareEngineer, it was because I wanted to tell others (peers, future employers) that I was different from the mass of indiscriminate hackers. Now I'm not so sure about the title. --WaldenMathews
Perhaps the difficulty is that we've been using "Engineer" to mean "professional". Perhaps we'd like to regard ourselves as members of a recognized profession, that at least tries to expect ethics and standards and yes, accountability - such as the professions of law and medicine, which have less to do with engineering than software development does. That is part of what SteveMcConnell writes about in AfterTheGoldRush (subtitle: Creating a True Profession of Software Engineering) - on which page, ironically, we went 'round on the definition of "engineering" and covered a bit of the same ground covered above. IMHO that book is a worthwhile and interesting read. If only McConnell had used "software development" instead of "software engineering", and avoided the whole controversy.
I recently described myself as "a professional software developer who cares about his craft". I don't care whether we call ourselves engineers or programmers or developers or professionals or craftsmen. What I do care about that we expect each other to give a good name to our field, and that we have some basic agreement on what that involves. I've seen enough cluster-f*ck projects that I can see why we don't have much credibility, and I don't want to be part of a profession that doesn't have much credibility. This isn't rocket science. The knowledge is out there on how to practice our profession well.
And I wouldn't expect everybody to agree with every tenet (not sure I do myself), but at least one starting point for an agreement on what is involved in giving our field a good name is a Code that was developed by the professional societies in our field (namely, the ACM and the IEEE Computer Society - see http://www.computer.org/tab/seprof/code.htm). Controversial or not, I think such a thing has the potential to be helpful. This was also part of the subject matter of AfterTheGoldRush, as were other potentially controversial topics like licensing of software professionals and accreditation of university curricula.
So to me the bottom line is to do as ThePragmaticProgrammer admonishes and CareAboutYourCraft?, regardless of what we're called. If someday there are some letters we can put after our names, I would hope that we could be justifiably proud of that. -- RandyStafford (JustaProgrammer, JustaSoftwareEngineer, SoftwareCraftsman, ProfessionalSoftwareDeveloper?)
BINGO! -- BobBockholt
Certification Is A Bad Smell?
This view may not be popular with conservatives, but I think an accreditation is simply a badge of mediocrity. Do you know how many Microsoft or otherwise "certified" people I've met who are totally incompetent? A friend, and very talented software engineer, and I were talking this weekend and saying that the day you have to get certified to get a job, is the day the profession becomes boring and we move on to something more challenging. Software engineering is young. Eventually, when things aren't changing daily, there will be more stable principles that can be measured. When that happens, for people like me, well, I will get bored on move on to the next "big" thing where I can at least be a bit player in blazing the new trail.
SteveMcConnell makes the same point in AfterTheGoldRush (that certification in technology doesn't mean much). But don't conflate accreditation of university curricula with certification in some technology. And don't conflate certification in some technology with certification in important software development knowledge areas. I agree that technology certification maketh software development competence not. Competence in particular technologies is only a minor factor in overall competence as a software developer. In my experience the areas of competence which have the most impact on project success are knowledge areas like configuration management, requirements development and management, estimation and project management, LeaderShip of people, and architecture and design. These areas are largely technology-neutral. In AfterTheGoldRush McConnell mentions the effort to define a "software engineering body of knowledge" (see http://www.swebok.org), and postulates that professional societies might someday offer certifications in this body of knowledge. The problem is that to date all we've had in our field is certifications in technologies. I would hope that certification in important knowledge areas, and graduation from accredited university curricula, would be more reliable predictors of competence.
Regardless, I think you (whoever you are - how about signing your post?) need to reconsider some of your assertions. Take "the day you have to get certified to get a job is the day the profession becomes boring" for example. I don't think anybody is predicting that certification will be a requirement for every job. However, for life-critical systems, the market or government may someday expect development firms to have at least some licensed or certified-in-body-of-knowledge software developers in positions of cognizance on those development projects, as is the case in civil engineering (if you were in a car wreck, would you want a hospital's emergency room's life-support systems to contain software developed by someone who thought certification was boring?). You say that "software engineering is young" and that "eventually, when things aren't changing daily, there will be more stable principles that can be measured". Software engineering is not that young. The term was coined in 1968, and many of the principles date back farther than that. The thing that is changing daily is technology. But there are stable principles in the areas of project management, requirements management, configuration management, and distributed system design, among other areas. And there are measurements (production rate, requirements growth, network traffic, etc.) that can provide information on whether these principles are being observed. I think this mentality of being "bored" with things that aren't "big" is one of the problems in our profession - it's antithetical to caring about your craft (as written about in ThePragmaticProgrammer). You need to look at it the other way around - demonstrating competence in these body-of-knowledge areas actually *frees* you to be creative and come up with innovative design solutions in whatever problem domain you're working in. By having approaches to avoid the typical chaotic development bullsh*t you can focus your energy on the really interesting parts. -- RandyStafford
If you were in a car wreck would you want a doctor who was recently "accredited" in the basic principles of brain surgery but had only done two operations to work on you? Look, you can draw all the wrong conclusions about my attitudes that you like, but it's not going to make me believe that you are right. We could go on this like all day, but I'm going to stop now. Hopefully someone will come along and refactor all this rubbish into something that makes sense. There are points on both sides of the argument. We are of different viewpoints. I don't think accreditation via testing that you know basic principles is going to do anything to improve the pool of software engineers. I do agree that the type of accreditation that KeithBraithwaite describes below based on actual past performance in the workplace would.
Right about what? What is "the argument"? I haven't said anything about certification by testing - that's your assumption. I also agree with Keith - certification by work history would be much more meaningful. I think there are two factors that damage the practice of software development: lack of knowledge, and lack of commitment or courage to apply the knowledge. I'm on a project right now that's suffering both factors, and it shows up in every lifecycle activity: requirements, design, configuration management, project management, etc. I'm tired of it. If I had some reliable way of knowing that people had the knowledge, then I could just focus on why they weren't applying it. Furthermore, I could try to avoid projects like this in the future. Life is too short for this crap. Opportunity is wasted. -- RandyStafford
I wish that certification could give us that assurance, Randy. I fear that certification only proves that a person is certified. I worked with one certified engineer who struck me as being particular incompetent. -- WayneConrad
Yeah, I know (sigh). Even with doctors and lawyers you still have to pick'em based on your "feeling" of whether they are competent. -- RS
I mostly agree with your point about accreditation (as you have defined it) being more valuable than certification. Still, I've met many-a university graduate who were also incompetent. I just don't know if just trying to cover the broad areas that don't change is going to produce quality engineers either. The problem is that even if you concentrate only on the areas that don't change, there are many that do and it is the responsibility of the engineer to constantly re-train throughout their lives. Most people, as they get older and have families and so forth, simply don't want to continue to study. If you have any doubt of this, I've got some C++ code written by old C guys I could show you. Although they may have been competent at some point, they are not any longer. Yes, their code "works", but if you saw, say, a house built in that hodge-podge, mixed-technique, unintelligible way, you'd never buy it.
That's part of the problem - to date there have been no accredited university curricula to teach the parts that don't change as rapidly - hence incompetent graduates. I totally agree with you on the other part of the problem - that too many "professionals" don't continuously educate themselves, in both fundamentals and technology. -- RS
Do you get my point about the C guys? If there had been accreditation of their university programs, they would have passed with flying colors... in C. Now they are just C++ hackers. Software engineering IS young, despite what you say elsewhere on this page. 1968 is a short time ago. The basic principles of mathematics and geometry and civil engineering are far older and more mature. Take a look at some bridges. Well, there is just not a lot of innovation going on about how to build a good bridge. The techniques are pretty much all explored. I think bridges are really great, but I would not want a job designing them because you are basically just solving the same problem over and over again using the same techniques. This is not interesting to me. To me personally. One day, software will be more like this. There won't be OO taking over procedural or whatever. Time will suss out the best methods and there will be a lot of generated code and things will get dull for me personally. There will be a book of 1,000 design patterns that have been tried and true and used for 100 years and you will have to be a genius to discover a new one that is really your own. I will want to do something else, can you dig? Of course, I'll be dead by then, so maybe I will be a software engineer the rest of my life.
Do you get my point about what changes and what doesn't? The C Programming Language is an example of a technology - which changes. The accreditation of university curricula in software engineering as described in AfterTheGoldRush (which is how we got started on all this) is concerned with more fundamental knowledge which, I contend, doesn't change as rapidly. Much of what we know about requirements management, configuration management, project management, etc., is derived from the field of SystemsEngineering (see http://www.incose.org), which traces its roots back to the 1940s. Of course this is not as old as civil engineering, and I agree that the knowledge crystallizes over time. But I'm not so sure there isn't still room for innovation. For example, we've long known that requirements management is necessary (even in XP, the planning game is based on user stories). About a decade ago began adopting use cases as a better way to manage requirements. Just within the past year I've begun using wiki webs to hold use case -oriented requirements specifications (see http://www.usecases.org/cgi-bin/wiki.pl?WikiBasedRequirementsSpecifications), and just within the past couple days I've thought about writing patterns on how to do that. I agree innovation is exciting, but I think it's still possible within the context of crystallizing knowledge. -- RS
Well, you just gave a couple of examples of how requirements gathering and management HAS changed recently. So, no I don't get your point.
It would be nice if you would:
Discovery Is The Interesting Part?
My original point however, is that when or if software engineering does get to the point where you measure competence on a multiple choice test, it will no longer interest me because most of the discovery (which is what I enjoy being part of) will be over.
Why does demonstrating competence in fundamentals of the profession mean that there is no longer room for discovery in technology, design, domain-specific solutions, etc.? I don't get it. -- RS
I did say most of the discovery will be over. Sure, you could still write symphonies in the style of Mozart today. And you might even come up with an original idea or two to add to the literature. But most of the discovery in that particular style is over. That is why people moved on to writing different types of music in the serious music genre. My argument is that by the time software engineering as we know it today is very mature, there will be some more interesting offshoot going on that is not yet cataloged and well-defined; and that is where I personally will want to be.
I'm just a passer by, please don't mind me asking: Isn't it more a case of being fit within present surroundings, or have we really soaked up 99% of all Mozart Style Symphonies in Mozarts time? That is too incredible for me to believe.
Some interesting responses there, although they tell us more about people's attitude to accreditation than accreditation itself. The kind of accreditation/certification I was referring to, chartered membership of a recognized professional body (in the UK that would be the BCS or the IEE, for software) has nothing to do with multiple choice tests, or memorizing API's. Rather, it has to do with raising your working practices to a professional level, including responsibility and accountability, and then showing continuous development as a professional. There are no exams to take. There is an examination of your work history in search of evidence for that professional development. -- KeithBraithwaite
Programming Is Not Yet Engineering?
The deeply offensive thing to me about the term SoftwareEngineer is that it implies a depth of knowledge and understanding that simply does not exist in our field today. In certain curricula, there is a good understanding of a wide body of knowledge that is necessary to practice competently in the modern era: you don't need to be an up-to-the-minute expert on materials science to build a bridge that won't fall down.
In isolation, I would find the term harmless or amusing. In the larger cultural context of modern programming, though, it is an indication of an unpleasant trend. The fact is that while the average person can have much better tools for creating software today than they did 20 years ago, our fundamental understanding of what goes into creating software has not changed very much at all. Furthermore there is a huge amount of cognitive science, psychology, and touchy-feely team dynamics that is involved in the "construction" of software that may have much greater impact on the complexity and quality of software that can be delivered.
That is just the cognitively poisonous meaning of the word in the context of academia. Being a SoftwareEngineer additionally implies that there are not only tools, but _materials_ involved in the software "construction" process. This is a comfortable lie that business managers tell themselves in order to assuage fears about risk. It has a dehumanizing effect on the profession, because there are no such materials except for people. Either huge amounts of busywork can be created to rationalize this fantasy, or people who are JustaSoftwareBricklayer? can start being treated like exchangeable parts in a predictable process by someone who is JustaSoftwareEngineer.
If we want to build a serious profession and a serious academic field out of Programming (or SoftwareEngineering, if we must) is to admit that we don't really know very much about it. Not only do we not have a good "canon" which is relevant, accepted, and not extremely controversial, as far as I know it is still unrealistic to believe that we have a generally accepted *metric* by which we could select such a canon yet.
If I'm the only one who feels this way, I guess it would make me JustaSoftwareIgnoramus?.
There is no software engineering, but, maybe, someday, there will be.
Say I'm designing a hypothetical piece of software (now there's a phrase for you: What a piece of SOFTWARE! (with disgust) Use it often, say it loudly!) that needs a certain kind of widget. If I were an engineer, I would be able to look up or compute the expected stresses this widget would experience in use, say, the largest number of bytes it would be expected to store at one time during the next 10 years. (Civil engineers work with 100 year storm maximums and stuff like that.) I would be able to look up data or formulae for different fully-specified widget implementations and choose the one (implementation) that satisfied some requirement. I should be able to choose a linked list implementation that uses is own memory arena and buckets so as to get a locality of reference figure that will guarantee the specified performance on the specified architecture. And all this without a line of code. THEN I'd be an ENGINEER! Until then I'm JustaProgrammer.
But civil engineers have millennia of work behind them. (Don't forget the ChemEs) MEs have centuries. EEs are close - they only have a few decades more on software, but they are also dealing, to a large extent, with things that are nailed down - a NAND gate has very specific inputs and outputs, and a FPGA is also tightly defined, albeit with more possible outputs. Software is seen as the ultimate flexible piece, that can cover the gaps between everything, in no time at all. That's why I'm hopeful the use of engineering in in the title will be justified eventually. I'm just not expectant. (It's all in the semantics.)
Naw, instead we have maximums, like "start with the simplest algorithm", "don't reinvent the wheel", "it's O(log2 n)".
Not bitter, just anxious.
Pop over to SoftwareBlueprints if you want more.
-- BobBockholt
A "software engineer" is a programmer who is allowed to have opinions.
The Mark of a Software Engineer: Professionalism
Take a look at other professions to get some clues.
A mechanical engineer (wrenchie) knows about strength of materials; knows about threads-per-distance and fastener surface area; knows about shear loads and flex; knows how to design stuff so it doesn't break.
A chemical engineer (bubbly) knows about covalent and ionic bonds; knows all that -ide, -ate, and -ium stuff; knows exothermic and endothermic; and knows how not to create a toxin rather than something benign.
An electrical/electronics engineer (sparky) knows Ohm's Law like it's one of his kids; knows reactive loads and the phase relationships involved; knows how to nail a spike to the power supply rail; and knows how to prevent his designs from dying due to heat buildup.
What does a software engineer (mushhead) know? What does he do?
A software engineer knows what off-the-shelf solutions are available; knows how to separate duties between software components; knows how to make components communicate and share information as well as operations; and knows how to make software that is robust, flexible, reliable, and easy to maintain.
Now: what is it about professionalism that y'all don't understand?
EditText of this page
(last edited July 27, 2005)
or FindPage with title or text search