The Life of a Software Engineer 519
Jonathan Wise writes to share with us an interesting bit of prose describing life as a software engineer. "I am, in the States, known as a Software Engineer. In Canada we're not allowed to call ourselves engineers, although the discipline is no less rigorous than any other kind of engineering. But perhaps its for the best, because 'engineering' describes only a part of what I do. A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy."
Re:I'm a software engineer. (Score:4, Informative)
WARNING: GNAA (Score:3, Informative)
Yes, you can call yourself an Engineer, if... (Score:1, Informative)
Re:Since when is engineer a coveted term? (Score:3, Informative)
In the USA, PE licensing is all but mandatory in the Civil Engineering field. It's very helpful in electrical engineering if you want to be a power distribution guy. Mechanical engineers can stand to have a PE license if they're going to be doing HVAC work. In other words, if you're going to be an engineer in construction, a PE license is very important to have.
If you're contracting out a big dollar engineering project, it's common to require a PE sign off on all designs. Where you typically don't find PE's is in unregulated industries in companies with internal engineering going on.
Easy solution to his problem. (Score:3, Informative)
2. Work a few years till you meet the requirements for registration.
3. Pass the professional practice exams and become a registered professional engineer.
4. Now you _are_ a software engineer, so now you can call yourself a software engineer.
5. Profit??
A few clarifications from the author of the post: (Score:5, Informative)
- A few people, who likely didn't make it to the site, like to make broad generalizations about geeks of this sort not having sex. I'd like to point out for the record that I'm married, have one child and another on the way. This suggests that I've had sex at least twice. And my wife is very beautiful.
- The intent was not to gripe about Canada's standards for the term "engineer." I only pointed that out the difference between my home country, and my current country of employ. I prefer the term "software developer" myself, but it doesn't really matter to me.
- The intent was also not to be pompous or fuel my own ego, it was to describe, as eloquently as I knew how, what most of us here on Slashdot are. Although the stigma is going away, us geeky types tend to be considered only that: geeks. When really there is art and beauty to what we do. I'm not even as skilled a programmer as I imagine most are, but I wanted to lend my prose to our art because I believe it is valuable. But flame on, if you must!
Thanks for reading, hopefully the site will be back up soon! I'd copy and paste the article text here, but I wasn't expecting this and don't have an offline copy!
Jonathan Wise
Re:Professionalism versus rigor (Score:1, Informative)
Drives me nuts when people state that "Engineer" is a protected term. Check court papers (on google) (or even wikipedia), both show that calling oneself an Engineer (of any type) is fair game in Canada. Just do not call yourself a Professional Engineer without the proper accredidation or you will be violating Canadian Laws. (again this does not apply in Quebec)
Re:No less rigourous? (Score:5, Informative)
So yes you can be a software engineer in Canada. But not by getting a cereal box certification from Microsoft. Perhaps graduating with a degree in Software Engineering from a University like Waterloo or Toronto, which do have software engineering courses.
Re:Yeah, right! (Score:3, Informative)
Even debugging (to be effective) requires the scientific method.
Re:No less rigourous? (Score:5, Informative)
You CAN be a Software Engineer in Canada. You just have to get a Bachelor's Degree in Engineering (or similar) with Software as your discipline. Then register with your appropriate body (APEG-BC in British Columbia) and there you go. The University of Victoria offers a B.Eng. in Software Engineering. For the first four years after graduation, you can call yourself an Engineer In Training. After that, you can get your seal and stamp as a Professional Software Engineer.
In other words, yes, you can call yourself an Engineer. Just not after mailing in box-tops to MS.
(I'm an EE. (in Training) )
Re:No less rigourous? (Score:3, Informative)
Sure. I was trained in aerospace so can at least tell you about some of the requirements of engineering. In the military there are many 'Mil specs' that must be met for any aircraft design (although less so for autonomous, unmanned vehicles). Within any company there are standard guidelines for the standard tolerances for various design attributes (such as tolerance for flatness, angle accuracies, cylindrical attributes, etc.). For civilian aircraft design there are many similar, but sometimes different from the mil specs, guidelines that engineers must follow and must be certified step by step.
For spacecraft you usually have tight tolerances, although less formal guidelines than in passenger or military aircraft design. On the other hand there are extreme guidelines for tracking the parts used to build a spacecraft, especially for NASA. They require that virtually every component must be tracked all the way to the lot and date on which it was manufactured (and only certain manufacturers are allowed). This is required even for small components like capacitors or resistors. Usually rockets and payloads that are intended for a low altitude (non-space) target have much less strict policies though.
In either case the design process is well documented and any significant change is usually signed off by another engineer. Each step of the design is documented and a reason is given for each change. While there are CVS style comments in software, you usually don't need explicit, signed paper in order to check in each change into your source repository. I don't know if this is the policy at aircraft manufactures but it certainly was at the spacecraft design company I worked at in college.
There are also rigorous, standard tests for aircraft and for spacecraft. Spacecraft must undergo many tests before a launch, including individual component tests, difficult systems-integration tests, and a shaking test that simulates the stresses of the launch vehicle. Any commercial jet must undergo months of tests after the first one is built. This is in addition to the countless simulations and physical tests they do for individual components during the design and prototype construction stages.
While some software companies may implement rigorous software repository and design standards, it isn't required by law as it is for aerospace or for civil engineering for that matter. Software writers aren't required to take a standard, national test in order to start their profession (unlike civil or mechanical engineers). And they certainly aren't held to any national standards for software design (although there may be exceptions for some specific problem domains such as aircraft control software or stock trading software for all I know).
Re:Software is different for a damn good reason (Score:3, Informative)
A great deal of crap software is actually pushed out the door against the objections of the developers that created it. Ultimately it comes down to marketing and PR and not the developers in most cases as to when a particular piece of software is ready to ship. Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping), because given the choice between a $50 piece of software that crashes once a week, or a $9000 piece of software that crashes never, almost everyone is going to pick the $50 one and live with the occasional crash. Does that mean developers like that? No, and most of them cringe whenever anything they wrote so much as hiccups, but sometimes they're just not given the chance or the resources (or clear documentation) they need to design it properly, because the bean counters know that the $9k piece of software the developer dreams of will never sell, but that $50 one they're puttering around with now is just about the right level already.
Software Engineer is fine according to HRSD Canada (Score:2, Informative)
According to Human Resources and Social Development Canada, Software Engineer is a perfectly acceptable term for that class of job. Being an American now working in Canada, I prefer '(software/web) developer' as software engineer sounds too 90s for me. But there are plenty of software engineers in Canada and no looming threat from the other 'engineer' subspecies.
Re:Yeah, right! (Score:3, Informative)
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html [vt.edu]
That's just one very classic example. There is plenty of software out there that can kill in large groups. Take the software flight control systems for modern jet airliners.
I grant you that control systems are just one kind of software. Financial systems however can destabilize entire nations if they fail and that can lead indirectly to loss of life in a variety of ways. Accounting for billions of dollars isn't something you take lightly.
Re:I work in Canada with a comp sci degree (Score:3, Informative)
And that is also why you should never be allowed to call yourself "software engineer". In a single short post you have demonstrated a contempt for regulation, law, clear communication, and honesty, which are all required for a Professional Engineer in Canada.
Despite knowing the regulations and laws behind the matter, you choose to willfully violate them, not to mention potentially defrauding others by impersonating a legal engineer.
Like others have said in this thread, being an engineer is not about being able to do your job, it's about accountability and the willingness to adhere strictly to established regulations and standards, something you obviously cannot do.
Perfection vs. due diligence (Score:3, Informative)
Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping), because given the choice between a $50 piece of software that crashes once a week, or a $9000 piece of software that crashes never, almost everyone is going to pick the $50 one and live with the occasional crash.
I really hate it when these discussions become black and white. Software quality is not a binary value. It is a sliding scale with diminishing returns for effort put in, on which we are for the most part still at the "dirt cheap" end.
I doubt I would want to pay the price of near-perfection. I'll leave that for the nuclear reactors, medical facilities and space shuttles. But the cost of due diligence — which I'll assume to mean taking reasonable, well-established, tried-and-tested steps to ensure quality in this context — is not the factor of 180 you gave. It's probably not even a factor of 5, and that's today when it's a relative overhead compared to those who don't bother.
What it would mean is having to actually follow reasonable development processes that worked. No more buzzword kool-aid for you, Mr Engineer! It would mean hiring competent people as senior technical staff instead of promoting substandard but slightly cheaper code monkeys, and spending the time and money to train those working under these senior staff properly. It would mean not letting sales and marketing staff dictate the schedules at the expense of even basic quality control.
Of course, if everyone were doing this and the industry as a whole grew up, this wouldn't cost much at all, because those same good practices actually make software development more efficient. It's just that short-sighted managers with their eye on quarterly reports and personal bonuses have an active incentive not to make the long-term investments necessary to reap those long-term benefits.
Re:No less rigourous? (Score:4, Informative)
Ha! You want to talk about small mistakes? Here's a small mistake: a contractor didn't want to bother threading a few nuts up a really long rod, so he cut the rod into three pieces and attached them to the beams they were supporting separately. No big deal, right? I mean, I wouldn't want to have to spend hours spinning nuts on a rod either!
Well, guess what: it killed 114 people [wikipedia.org]! So don't go telling me that software is "different" because of small mistakes. Because it really damn well isn't!
Re:Yeah, right! (Score:3, Informative)
Until some real bad judgment sees you putting a small plastic part into the door handle, making it potentially hazardous for children - we've seen it before and we'll see it again. Or maybe during all the cost cutting the company opts for shoddy plastic that deforms and gives off toxic substances in a particularly hot summer. Or maybe the plastic becomes brittle over time, allowing it to snap off and form sharp edges.
I was personally involved with plastic component design with car radiators - the number of issues you can have with them are immense, the same goes for almost every other branch of engineering. Something that on the surface seems simple and completely removed from life and death situations... are actually not. All of the examples I've brought up are perfectly plausible, and in fact I'd wager some of them have already happened.
Full Article Text... my poor host is choking! (Score:1, Informative)
In fact most employers I've worked for actually have rules in place to suggest that I not try to fix my own computer. There's these organizations, some (not all) still stuck in the 70s and 80s, called "I.T. Departments" who's official purpose is to fix computers -- but who's actual purpose is to attempt to prevent their users from doing anything dangerous (read: useful.)I do not, and have never, worked in an "I.T. department," although I've volunteered those skills I have in that area on many occasions. In actuality, my job is much different.I am, in the States, known as a Software Engineer. In Canada we're not allowed to call ourselves engineers, although the discipline is no less rigorous than any other kind of engineering.
But perhaps its for the best, because "engineering" describes only a part of what I do.A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy. The process of developing software differs from organization to organization. Some are more "shoot from the hip" style, others, like my current employer are much more careful and deliberate. In my 8 years of experience I've worked for 4 different companies, each with their own process. But out of all of them, I've found these stages to be universally applicable:
Dreaming and Shaping
A piece of software starts, before any code is written, as an idea or as a problem to be solved. Its a constraint on a plant floor, a need for information, a better way to work, a way to communicate, or a way to play. It is always tied to a human being -- their job, their entertainment... their needs. A good process will explore this driving factor well. In the project I'm wrapping up now I felt strongly, and my employer agreed with me, that to understand what we needed to do, we'd have to go to the customer and feel their pain. We'd have to watch them work so we could understand their constraints. And we'd have to explore the other solutions out there to the problem we were trying to solve.
Once you understand what you need to build, you still don't begin building it. Like an architect or a designer, you start with a sketch, and you create a design. In software your design is expressed in documents and in diagrams. Its not uncommon for the design process to take longer than the coding process.
As a part of your design, you have to understand your tools. Imagine an author who, at the start of each book, needs to research every writing instrument on the market first. You have to become knowledgeable about the strengths and weaknesses of each tool out there, because your choice of instrument, as much as your design or skill as a programmer, can impact the success of your work.
Then you review. With marketing and with every subject matter expert and team member you can find who will have any advice to give. You meet and you discuss and you refine your design, your pre-conceptions, and even your selected tools until it passes the most intense scrutiny.
Once you have these things down, you have to be willing to give them up. You have to go back to the customer, or the originator of the problem, and sell them your solution. You put on a sales hat and you pitch what you've dreamt up
Re:No less rigourous? (Score:4, Informative)
The result is that our software takes a minimum of 8 to 12 times longer to roll out than it did before. It is now so slow that our developers are starting to lose their skill set because there is so much downtime.
Where before we could roll it out-- suffer the "$30k" loss, fix the bug (which takes weeks of testing but only a few minutes in production to flush out), and put in a fixed build in a total of 2x the time.
And the real kicker is that we STILL get bugs in production after all that testing because the best test site in the world doesn't simulate 70,000 users hammering on the software. (and the company doesn't begin to pay for the "best" test site anyway).
Bullshit. No firmware on turboprops. (Score:1, Informative)
I call bullshit.
No you can't thank them. For there are NO software engineers writing fuel injector firmware for turboprops, at least not for any that are expecting to be certificated by the FAA to fly in the USA.
All turboprop engines currently certificated for use by the FAA on domestic aircraft all have mechanical fuel pump and injection systems on them. In order to gain certification, these engines must be able to continue to run with all electrical systems/subsystems failed. The FAA will permit a starter/generator system to fail after the engine is started, but if the engine is not capable sustaining running and making full power until you intentionally shut it off or it runs out of fuel, it will not be certified to be installed on a certificated aircraft in the USA. So sayeth the FAA.
Re:Engineering Whining (Score:4, Informative)
"The professional association allows them to hide behind a large entity, with deep pockets, such that any litigation against a single individual, is futile."
Um, no. The Professional Engineer Association of which I am a member has about 18000 members and we pay about $225 per year. An annual budget of $4 million is not "deep pockets" by anybody's definition, at least not when stacked up against corporate clients with several orders of magnitude more money. More to the point, the Association doesn't spend _any_ of its money defending engineers against litigation for faulty work. They do spend it pursuing discipline against incompetent or unethical members. The record of discipline against members is public, you can usually find it on their websites. Try APEGBC, PEO or APEGGA for examples. Every month we get to read about a handful of cases where somebody is disciplined for substandard work.