This was the first post I ever read by Patrick. It and Joel Spolsky's blog should be regarded as compulsory reading for all CS grads. Definitely set me on the right path.
I think a good follow up of "don't call yourself a programmer" is "Don't look for a job". The moment you start looking for a job, you're pretty much that "Java programmer" again. Somehow, the people I meet who can't find a job are those who are looking, while those who speak about their employment in literally any other way than "looking for a job" never seem to have a problem. I don't know exactly which way the causation link works (maybe people who are good at getting jobs are privileged enough to not have to think about it in that way), but I'm pretty sure that the word 'job' and mental model associated with it is not optimal.
>Somehow, the people I meet who can't find a job are those who are looking
This is a pretty clear example of a biased sample. If someone can find a job easily, then you won't spend much time looking for one. "Don't look for a job" is terrible advice for people who don't have jobs. Also, if you can't think of a good reason for a causation link you should really consider that maybe it is due to a confounding variable (there is no direct causation link).
Eh, I phrased it badly. Wasn't trying to distinguish between employed and unemployed people, but rather a distinction between those who don't have a job and say "I'm looking for a job" and unemployed people who phrase the same idea in a different way..
I think the point still stands, the longer you spend unemployed the more likely you are to describe yourself as "looking for a job" (unless you have given up entirely). If someone describes themselves as not looking for a job when they don't have one, it is possible they are just telling the truth, and when they do decide to look for a job they can find one quickly. I am pretty skeptical that thinking of yourself as looking for a job really causes you to have difficultly finding one - like you said, there isn't any readily apparent direct causative link.
Is this a variant of Spolsky's line that no good programmer should ever have to look for work; if you are good, work should just fall into your lap? Because it's horseshit.
Maybe this is true because I've only worked in a software boom in a large city but the only reason I've been out of work in the last 5 years since I switched from working in politics to coding full time is because I deemed the jobs available either undesirable or the pay insufficient. And when I say the pay was insufficient I'm still talking something well above median income. So Spolsky seems pretty right on, at least for the moment.
Trust me, this attitude comes from never having to survive a severe tech downturn. Consider yourself fortunate! As someone who survived two, I can tell you with utter certainty that there are very few people with jobs just falling into their laps when your profession is suffering double-digit unemployment.
> "Modesty is not a career-enhancing character trait"
It's hard to overcome though. In a previous role, I was the main UI dev on a rewrite of a top 10 ecommerce site's checkout process and also had a lead role in designing the checkout API that handles $billions in revenue a year. But it was really hard to get myself to add any of that to my resume or linkedin profile. Like I was worried about someone somehow calling me on it, even though it's completely true.
Of course, now that I've written that, I feel like it may have more to do with impostor syndrome than modesty.
No, if you sell widgets, making widgets is a profit center. It has assignable revenues. Cost centers are things like accounting and HR. Engineering can be either a profit center or a cost center, depending on the line of business.
Wouldn't Apple see manufacturing as a cost center? The act of manufacturing costs Apple money, but on its own doesn't generate any revenue.
Apple probably sees design, marketing, and sales as its profit centers. I don't know about Apple specifically, but some companies I've dealt with view manufacturing as a black box: input design and money, receive widgets in return. Good design enables marketing, and marketing enables sales, so the design->marketng->sales pipeline is viewed as the profit center.
A lot of companies, even software companies, see their developers as a similar black box: input ideas and money, receive software you can market and sell. Depending on a company's culture, it can be hard for developers to shift this perception. In some cases, I'm not even sure it is the wrong perception. In SaaS companies, it is easier to tie the work of developers to the revenue it helps generate than in an enterprise software company where selling is going to require a professional, high touch sales force regardless of how good the software is.
I was drilled from birth by PE-license-holding parents that "Engineer" is a regulated term that you can't legally describe yourself as without the license.
They're correct; it's just that the rule is flouted to the point of non-existence in tech.
Wherever this guy has worked is where I never want to work. If people can't appreciate the value your engineers create then that's not a place to work. If this guy's advice applies to your job, get a new job. I'm not going to work at a place where I'm worried about "attaching myself to the company's profit center" and other bullshit and I've been a happily employed programmer for 9 years now.
This is a very interesting comment and I like to think the same way. That is the way that seems to bring most happiness to me in professional life. The question is, how do we recognise these places before joining them?
I don't think dice are a good analogy since previous jobs affect the ability to get better subsequent ones. Yes, names on a resume and knowing the right people are important.
You don't get an infinite number of rolls in your career though. If you rolled a low number, you might not know it until after a few years. A better analogy is a baseball game. You get a few at-bats throughout your career, and that's it, and you generally have to do them serially. Either you swing for the home-run and risk missing, or take the safe base hit and never end up scoring a run.
An important point to be sure, although you don't exactly keep the max. It's more of a press-your-luck type of operation where you can't necessarily revert back to the max if you've already left it. Still a very valid point that you can switch jobs at any time you're unsatisfied.
I've done the startup thing. I've done the corporate LOB thing. They both can be great, they both can suck. Frankly, it mostly depends on your boss.
But the point of the article is to not pigeonhole yourself. Don't be that guy who wrote that library, or the guy who maintains that app. Be the guy who brings value to the business. Be the guy who is considered an asset no matter what role they have, because you are working towards the goals of the business. Be the guy who knows when to say, "Yes, I can code that, but we can buy it just as cheaply, and let me focus on more important details of our business."
> Yes, I can code that, but we can buy it just as cheaply, and let me focus on more important details of our business."
Uh no. I code, that's what I do. I'm fine with being laid off if that's not creating value. I can code somewhere else.
If you go into a non-engineering role, you are sacrificing your engineering career for temporary survival at your current job. The next engineering job you apply to wont probably like that you haven't done SWE work for whatever amount of time. Just pull off the bandaid and get a new job.
I'm an engineer. I want to be good at engineering. I'm not interested in the rest of it. It's not my job to make sure the engineering tasks line up with business success. My job is making the math and the code work. Division of labor. I don't want any other role. If engineers aren't valued I'll go somewhere where they are. There are lots of engineers creating value all over the place. There's lots of opportunities out there, there's no reason to have to sell yourself if your skills don't.
While I certainly sympathize with this attitude, these days I simply can't afford to think this way. If all I do is write code from a spec, what separates me from the millions of other 10x cheaper coders offshore? My native English skills?
As an engineer it's easy to think "yeah, well I write good code.." but in my experience you will never be able to adequately demonstrate that to a potential employer during the interview process.
> I want to be good at engineering. I'm not interested in the rest of it.
Being "interested in the rest of it" makes you a better engineer. Indeed, there's an argument to be made that that's part of what makes you an engineer.
How do you know whether you're creating value if you don't care to know what's valuable? How do you expect to be able to make yourself worth hiring if you don't know and won't learn how to make your paycheck worth signing? How do you intend to build tools that make people's lives better if you can't be bothered to understand what they need?
I personally don't care what you consider to be an engineer. I solve engineering problems, and I solve them well and I get compensated for it. I want to create great physics systems in game engines. It's not my problem to solve to make games built with that engine a success. I want it to succeed, but I don't get involved. That's not what I'm good at.
It's part of a larger series of wise advice that seems to be appreciated nowadays. It goes like this:
* don't call yourself a programmer, you are a revenue-enhancing solution provider
* especially don't call yourself an X programmer, you will use whatever tool is necessary to complete the project and provide value
* don't look for a job, this shows that you're weak. Let the jobs come to you.
* keep yourself current with the latest frameworks and languages to prove that you can adapt to new challenges
* having at least one but ideally more open source projects on github proves that you have passion
* make sure you're a culture fit. Do go to the company parking lot beforehand to see what others wear.
* wear nice clothes, brush your teeth and eat your veggies
* <insert your own here>
After doing all of this you will probably succeed in avoiding having your job outsourced or having that promotion given to someone that's an even bigger bulshitter than you. Congratulations! Now you only need to have some minor plastic surgery done and learn a few recent cultural references in order to not make your colleagues uncomfortable.
You are well on your way to become the perfect solution provider citizen!
I don't think this will be a terribly popular opinion, but I want to offer a counterpoint. Do call yourself a programmer, because we don't deserve to call ourselves engineers. You want to know some things that define actual engineers, as the term is regulated in some countries?
Real engineers have certification: you know, that thing that indicates that you can actually do your job worth a damn. What do programmers say whenever the topic of industry certification is brought up? Usually, furious opposition.
Real engineers have accountability: engineers in a lot of other industries can be civilly or even criminally liable if their broken shit hurts somebody. What do programmers say whenever the topic of accountability for broken software is brought up? Usually, furious opposition.
Real engineers have unions. You know, that thing that keeps your labor from being exploited by-- just to give some hypothetical examples-- intentionally confusing and exploitative equity renumerance, or floods of H1-B workers. I shouldn't even have to tell you what the attitude towards most programmers is to unions, at least in America.
And whenever the topic of certification, or accountability, or unions, is brought up in the context of our discipline, the response is almost invariably, "Well, it's different for us, because $REASONS". Okay, fine, it's different for us, but then we shouldn't call ourselves engineers, because it's clearly a category error.
I've got certification - I completed the W3Schools HTML intro.
What would you put in software certification? If you focus on high-end CompSci stuff, it won't be relevant for the 99% who spend their careers building CRUD apps. If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
I agree that there could be industry certification on topics like security and perhaps accessibility. But on everything else, the answers depend on so many factors, they can't be certified in a meaningful way.
Also, some of the best software engineers I know don't have certification because they struggle with exams. The ability to pass an exam doesn't make you a better engineer.
Certification is nice in theory, but in practice would probably lead to worse results.
I call myself a software engineer because it's what managers call me. As long as I don't claim to be able to build a bridge across the River Thames, I don't see the problem.
This is absolutely inane. Do you think that the FE/PE only focuses on things that you do every day?
It's to give the world hard proof that you actually UNDERSTAND what is happening and allows you to actually accept responsibility to create things that may actually affect peoples lives. Sure its useless if all you do is work on a react/angular app, but not all software is your standard CRUD app.
Of course a lot of software is much more complicated than simple CRUD apps. I don't touch them because it would be irresponsible for me to do so.
But there's no clear line where an app stops being CRUD and starts being something more, so there's no clear line where you stop needing a CRUD programmer and start needing a software engineer.
There are some that clearly need certification, and often that is an explicit requirement of the job.
Just don't get too hung up on the job title. Managers want to believe their software is so complicated that they need a software engineer to build it. I'm happy to go along with their delusions if they pay me.
I agree with both the parent and this comment; this is why when i read "Software Engineer" i don't consider it to fit in the same bucket as any other "Engineer" in general.
As a "guy who writes code" - call me whatever you want, i could probably give myself a fancy title and get away with it, but I am one of the very successful (When compared to the 99%) people who didn't finish school but managed to get by in the tech industry very comfortably. Life is already great, perhaps I just don't deserve to get everything my way.
Exactly. If I had been born 100 years earlier (maybe even 25 years earlier) I would have had a low paying menial job. I'm blessed to be in the job that I am, with the pay that I receive, and I am grateful for that every day.
I don't use "software engineer" as an ego thing, but because it communicates better the variety of knowledge I have to people that barely understand how to turn their computer on. I get better pay, my employer is happy, everybody wins.
Note—tying this back into the article—a lot of people can write code. It's the person who understand what they're writing, why they're writing it, and why it works that you want to hire, so you would not be well served walking in with JUST the "programmer" title. That's a title many in the world can claim without being worth a hire.
> If you focus on high-end CompSci stuff, it won't be relevant for the 99% who spend their careers building CRUD apps.
Engineer is not a guy putting things together on an assembly line. Engineer
needs to understand things that are base for his/her field.
> If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
My tools that are dozen years old work just fine, thank you very much. And
they work faster, more transparently, and more reliably than most of modern
buzz, if we're at that.
So certification is more than just an exam. Usually it implies receiving accredited post-secondary education and registration with your governing body and going through a mentorship with an existing P.Eng. So in my case I got a B.ASc degree, joined my provincial regulatory body, wrote an ethics/law exam and did a 48 month mentorship. Now, the reason things are treated this way for Professional Engineers is rooted in history. I can't say that I believe all that is entirely necessary for all software engineers but if we're to use the title we follow the rules.
Really, the ideal system is self serving. You create a framework of professionals that self-govern. The Professionals appointed/elected to the governing body are responsible for ensuring the certification is relevant to the profession. I somewhat prefer the mentorship program over testing individuals on knowledge in their domain because your mentor(s) will be a better judge that you're understanding concepts, regulations, rules, and needs better than any exam will test for. Like you said, knowledge that I apply on my career is very different from knowledge you apply in yours.
Another thing that I want to say though is that I don't feel certification is necessary in software unless you're in a position that carries potential harm to a person's safety/wellbeing. There's a few exceptions to what that entails exactly but that's not really the point of this discussion. Generally speaking, I don't want someone with a layman's understanding of code to be programming things where a person can lose their life due to an oversight. In the same way that Professional Engineers in Civil, Mechanical, etc. use their professional seal to say that "my specs meet all relevant modern standards of safety/design/etc", I want software engineers programming that medical device or safety equipment have the same accountability. Currently there isn't an international recognition of "Software Engineer" as a title to say who is working on that device has been vouched for professionally.
> I want software engineers programming that medical device or safety equipment have the same accountability.
There is a difference here in that someone working on a medical device isn't directly offering their services to the public, and the work-product is subject to external testing and oversight.
> some of the best software engineers I know don't have certification because they struggle with exams
Hm... ok, I'm not sure I buy that. How are you defining "best"? I suppose I can accept that there may be a handful of people (worldwide) who can produce amazing software but are somehow unable to memorize and regurgitate facts, in the same sense that there are people in the world who can recite all the digits of pi but can't tie their own shoelaces - but I have a hard time believing that such people are very, very rare.
That depends on what you are trying to optimize for. If you are trying to optimize for consistency of language sure, you're right, you should not call yourself an engineer. If you want to optimize in managing your value in the eyes of a person who wants to give you money it's a different story. It's possible this advice doesn't work in every country.
So since my bachelors degree is 'Bachelors of Science in Computer Science: Software Engineering', I shouldn't be able to call myself a software engineer?
If you're in the US and want to be extremely pedantic/annoying, then no. ABET (the engineering accreditation society in the US), doesn't have "Software Engineering" as a valid discipline.
It is a valid engineering discipline. Engineering is about making useful things, from metal, from concrete, from semiconductors, and from software. Engineering requires the application of methods that use science, mathematics, and processes that have been studied to invent and construct solutions. This is what Civil Engineers do and this is what Software Engineers do too.
I see nothing wrong with someone calling themselves a software engineer that has both training (a CS degree for example) and experience (a few years) working in software development.
Let's look at the numbers. Texas and Florida have a PE test for Software Engineers. In Texas the numbers are (see [1]):
2014: 6 people took the test and 2 passed.
2015: 5 people took the test and 2 passed.
2016: 3 people took the test and 2 passed.
Only California has more programmers than Texas, see [2], and it appears that there are 6 Professional Engineers at most in Texas in the field of Software Engineering out of over 20,000 programmers.
My conclusion is that the title of PE in Software Engineering is currently pretty meaningless in the US.
The Computer Engineering degree I have is from an ABET program, it was pretty even on CS/EE. No regrets, except for the times the hardware guys act like I'm just a software guy and the software guys act like I don't know anything about software because I'm a hardware guy. XD
* Demand, since it is a new exam very few companies will be looking for a PE in software engineering.
* Supply, it's not just taking the test (starting with the FE) but you also need to have worked under a PE in the field (hah!) or had relevant experience to waive that requirement (this is a lot more vague and determined by the state). I would wager that most with relevant experience in the field are also not wanting to bust ass to study for a PE exam that no employers are demanding.
I'll be interested to see how long it takes for this to be more common. When I graduated (computer engineering) the consensus was that unless we knew our job would require a PE in the future that we didn't bother even taking the FE exam.
Why does some random organization get to decide whether or not people are a thing? It'd be one thing if it was the government, but this is like saying that no one can be a "soccer player" unless the USSF says so.
Soccer players aren't responsible for designing walkways that won't catastrophically collapse when loaded. Also, not everyone in an engineering type role is a PE. There are some circumstances where the PE double/triple checks work done and signs off on it, putting their license (and livelihood) on the line if the work is shoddy.
I have absolutely no problem with a non-government organization claiming authority over something like "ABET-Certified® Engineer". I have a giant problem with a non-government organization claiming authority over the generic English word "engineer".
In the US it's more that the government claims authority over the phrase Professional Engineer [0], but ABET accredited programs feed into the FE exams which feed into the PE exams which are required to be licensed by the government. Little bit messier than either GP or you implied.
[0] and probably also offering "engineering" services but I'm not sure of the extent there
Yep structural engineering design in most countries doesn't need to be done by a registered professional engineer - just signed off by one. A lot of offices will have graduate/junior engineers that are not registered yet (but often working towards it) doing a lot of the donkey work. But they aren't responsible for it - the registered engineer who signs off on their work is.
> this is like saying that no one can be a "soccer player" unless the USSF says so
No, it's like professional soccer teams saying "I won't hire anybody who the USSF didn't say is a 'soccer player' because they have a good track record of establishing credentials and I trust their judgment".
Are certification, accountability, and unions really the defining characteristics of engineering?
Directly from wikipedia:
In 1960, the Conference of Engineering Societies of Western Europe and the United States of America defined "professional engineer" as follows:
A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character. It requires the exercise of original thought and judgement and the ability to supervise the technical and administrative work of others. His/her education will have been such as to make him/her capable of closely and continuously following progress in his/her branch of engineering science by consulting newly published works on a worldwide basis, assimilating such information and applying it independently. He/she is thus placed in a position to make contributions to the development of engineering science or its applications. His/her education and training will have been such that he/she will have acquired a broad and general appreciation of the engineering sciences as well as thorough insight into the special features of his/her own branch. In due time he/she will be able to give authoritative technical advice and to assume responsibility for the direction of important tasks in his/her branch.
Basically, what defines a "real engineer" has pretty much nothing to do with engineering? I'd rather define engineers as people who have the skill and know how to engineer.
Those three are claimed as necessary conditions, not sufficient conditions. I agree that "engineer" also implies some degree of technical skill (like understanding the difference between sufficient and necessary).
The article does NOT say to call yourself an engineer instead, it's not nearly that pedantic. It says to say you increase revenues and/or decrease cost, not that you sling code.
What about the part where some of us have engineering degrees and certifications for things like network engineering? Or just various certifications at all for technology specific areas?
I hate being called a programmer, am okay with developer, and call(ed) myself a software engineer, and that's why my title said as well. I wasn't the director of programming, and I wasn't running a team of programmers. I ran the software engineering team and I hired software engineers.
In my mind, they're not interchangeable terms and have specific meanings. A programmer is someone who can write code, cobble together applications in a generally slapdash fashion, and does not apply a lot of creativity or thought to the how's and why's of what they are doing. They are the front end web dev who can't write pure JavaScript and have to use jQuery and a bajillion other includes just because they don't know how or care about the implications.
A developer pays some attention and care, has a reason why they may have made certain decisions, and is generally thoughtful about their core areas of knowledge. Maybe they're not as thorough, have a more narrow window of experience, or generally don't care about 'those other things' like networking, operating systems, protocols, etc.
A software engineer knows about OSI, the types of protocols in use by their application, the pros and cons of various libraries, and has a reason that can be backed up with at least some empirical evidence for any of the choices they make. They step back and look at the problem they're solving as a whole instead of piecemeal, and they're generally not shortsighted. They apply rigor, experience, and research to all phases of what they're working on.
We were all programmers and developers, some of us get to software engineers if we want- but it's really about the rigor and discipline you apply to your craft.
I agree that the fundamental aspect is the accountability, however unions don't mean anything for the quality of your work, and there are ways to certify specific areas of knowledge already.
Ha, I just came off a few hours of writing some, but definitely not my primary languages. A project I was committing some code to most recently was using Babel and Webpack and had like 20+ include statements at the top for some very rudimentary things.
Man I'm sorry but everything you are saying, at least in the US, is completely contradicted by reality.
Some engineering fields have all those things you describe but it is usually because there is a high degree of physical risk to the public, like structural engineers for example.
Mechanical and Electrical engineers, for example, at most companies are hired without any such certifications, unions, oversight, or any of what you've mentioned. I have a degree in EE and CS and have worked in both fields doing everything from IC design to app development and the hiring process, oversight, etc has been the same in almost every case - no membership or union required. I have friends who work as ME, Chemists, physicists, etc and the same is true for all of them except in the exceptional cases where they are working on a medical device or something.
Really all those things you mention at most companies for most fields of engineering come down the the company culture itself and the technical leadership at those companies.
The really funny thing about your take is that in most cases I find that high level software developers have a much stronger cult of engineering excellence that any of those other fields. If you saw the "process" most EE's used to ensure high quality engineering at large companies like Intel you would be horrified. And definitely don't ask those EE guys to write any code, it will almost certainly be terrible.
Also, usually I hear this line of reasoning from people in other engineering fields who, in my opinion, are just being babies about the fact that software is so accessible and there are brilliant people doing great work who nonetheless didn't go to university. It is really surprising to hear this come from someone who is actually a developer themselves.
I hear you. I was more just ranting and did not expect this to be the top comment; I need to be more careful about that. There are a changes in the industry I'd like to see and this seemed like a rhetorically punchy way to get that across, but I'm not really fundamentally opposed to the term "software engineer", I just wish we had the institutional rigor and care for the craft that I see (or at least, perceive) elsewhere.
While there is an exam and better employment prospects may be had for those with a license, getting a license usually requires "acceptable, progressive, and verifiable work experience in the industry."[1] This often requires an engineering mentor to assess your work which usually happens if you work under a licensed engineer. Licensed engineers are hard to come by in many high tech and computer industries and with many companies strict rules on secrecy (i.e. NDAs) it can be difficult to get a licensed engineer in your field that is outside your company to assess your work.
I tried to see if there was an opportunity for an engineering mentor at my job (One of the big four) and I was unable to get anywhere. It seems that it is better for our job prospects to get a job at a prestigious/interesting company and gain experience there than try to go through the licensing process.
Yeah, don't do this in Canada, or the professional engineers association can come after you. Only certified members of an engineers professional association can use the title.
To be clear, it is illegal, for example, to pass around business cards that say 'Software Engineer' if you're not certified.
As an amusing example, in the province of Ontario, people with the Microsoft Certified Systems Engineer certification are allowed to use the title 'MCSE', but not its expansion, because it contains the word 'Engineer'.
However, you are always allowed to state your degree, so you can say, {name}, B. Eng., or M. Eng., as the case may be.
*At least, in Quebec and Ontario - the legislation is province-scoped, I assume other provinces are similar.
Interesting. I can look in the corporate address book, and we've got people in Burlington, Ontario who have titles like "SW Quality Engineer" and "Group Leader-SW Engineer". I wonder if that means that they can't put their official titles onto business cards.
Coming from a US perspective, I feel like "engineer" on its own is a descriptive word. "Professional Engineer" is a trademarked title, and that seems reasonable. Do I have certification as a PE? No. Do I think it's reasonable to describe what I do as software engineering? Yes. To me, it implies that I take part in planning, designing, implementing, supporting, and retiring software. "Programmer" connotes that I took someone else's design, wrote to that spec, and handed the results off to someone else, rather than taking part in the entire lifecycle.
The opposition to certification and professional organization is truly bizarre. It would likely do much more good than harm to the profession of software engineering, yet that furious opposition always ensues whenever you bring it up.
In addition to the points you make, real certification (as opposed to a four year degree, which anyone willing to go into debt can get) would simplify interviewing and reduce the "whiteboard hazing" and "throw darts at a dart board" methods we use today for finding good candidates. Organization would help fight for a proper career path for programmers, rather than having to, as an individual, constantly negotiate and hop from one employer to another in order to advance.
> real certification ... would simplify interviewing
Well, I admire your optimism, and as much as I wish there were professional licensing for software professionals, I doubt that any licensing exam could ever be so rigorous that at least a few charlatans wouldn't be able to squeak through it.
A four year degree is a certification. What would a "real certification" do differently to make it "real"?
> would simplify interviewing and reduce the "whiteboard hazing"
I doubt it. If a certification is too specific it'll exclude an enormous amount of engineers. Make it too broad and then companies will still have to do the same interviews they do now to verify that a person is a good fit for the specific job opening they want to fill.
I'm eager to hear your proposal on a certification method that doesn't exclude wide swaths of existing and future engineers based on your specific definition of what a software engineer is and isn't, but at the same time is specific enough that having the certification actually means something to other people.
>The opposition to certification and professional organization is truly bizarre. It would likely do much more good than harm to the profession of software engineering, yet that furious opposition always ensues whenever you bring it up.
Most likely it is because a great many programmers without a formal college education or with a non-CS college education think that certification might be used to demote them to second-class citizens. And, without commenting on the rightness or wrongness of it, they wouldn't necessarily be incorrect about that either; such an exam would most likely have a strong focus on CS topics.
I thought I was the only one who though this. I am not a software engineer the same way I am not a software doctor or a software banana for that matter. Reminds me of, was it Rosanne Barr?, who coined "Domestic Engineer" and we all laughed. Words matter. I can see from these comments that we are alone but at least it's not just me anymore!
Software doctor almost sounds like it could be a useful term for someone whose role is diagnosing and curing software defects. But the term "software engineer" is already suitable for someone who applies scientific/engineering rigor to the production of software.
you're pointing out ways in which the culture of software development/programming is different than the culture of other forms of engineering.
my response to this is simple: do you think that words matter? If so, which word do you think is most effective in communicating with people outside of the field?
there's room for people to come up with radically different answers to those questions, but my answer is that "Software Engineer" matters when communicating with non-programmers. When talking shop with a fellow practicioner it doesn't matter much what word you use. This is just about communication with the outside.
You want to know some things that define actual engineers, as the term is regulated in some countries?
That's great if things work that way in other countries. But in the States, things work differently (in the software industry, at least). And like it or not, are unlikely to change (any more than this country is likely to shift over to the metric system) anytime soon.
And unfortunately the term "programmer", as a resume heading, has come to be laden with negative baggage in various ways (as detailed in the original article). So in practical terms, you are 1000% better off calling yourself an engineer or developer (rather than a "programmer") in the U.S. at least.
I'm pretty sure that's not true, and in fact one of the distinctions about a professional is that he doesn't belong to a union: he is both worker and management.
A professional is in sort of a weird position union-wise though. He often is part of some organization of professionals. That organization doesn't negotiate one employment contract for all (or even large portions of) its members, but it does have a lot of sway over whether he can be hired in that profession and give him a convenient higher power to support his refusal to commit some sort of professional misconduct. "Union" definitely has the wrong connotation though.
Programmer might be a little archaic but to me it conveys a sense of humility possessed by the people I most admired when learning the craft.
Plus it's baked into the title of "the Art of Computer Programming" by Donald Knuth. How many people can really say they have mastered that art? It's hard to believe there's any qualification more worth striving for or harder to achieve.
Engineering is about solving problems using well-understood principles and processes that have been thoroughly tested (as opposed to science, which tries to discover or invent new principles and processes). It has nothing to do with certificates, legalese, or unions.
Programmers have a lot of engineering work supporting them in different ways and sometimes they do actual computational engineering. I don't have a problem with calling myself a programmer. Patrick M does because he wants to translate his work into the language of corporate and marketing communication because he thinks this will make him more valuable. I'm not sure that's a good strategy except to create a kind of odd cloud around what he's doing. Programming is not so mysterious to management anymore. They know it's valuable. Those that don't, well, I'm not sure you want to work for them anyway.
In a promotion review, being able to say my project drove $X in revenue wins almost every time against any other metric. It's easy to state and directly relates to the companies business goals.
I always have been uncomfortable with the honesty of those kinds of claims (although I hypocritically use similar language on my own resume). Say there were 100 people on the project that drove $X in revenue: Was the contribution evenly distributed? Did your contribution account for $X/100? If you were not on the team, would it have driven $X-Y revenue (in which case you only added $Y in value)? Surely employers aren't dumb or fooled by such wording.
You're not claiming you personally drove $X in revenue. You're claiming that the project did, and that you were critical or at least instrumental to its success. If you can back those claims, you're not lying and you have no cause to worry over your honesty. If you can't back them, don't make them.
Customer demand by itself is worthless in real terms. You have to give people something to buy. Having successfully done so, there's no reason you need to shy away from saying as much.
Which you could say about pretty much any feature on a customer based business model.
But customer demand is only useful if you can turn the demand into a sale and a happy customer. Measuring the conversion of an interested user to a customer is how you measure return on investment for features.
If what you did meant an increase in revenue from those customers, then it is fair to say it drove revenue.
I would love to have a proper PE type thing for Software. I find it absolutely infuriating that "developers" refuse to accept accountability for the things they write.
Then they'll just eliminate QA departments. If the guy doesn't produce perfect code, oh well, he's the liable one. Fire him and get someone else. The business takes on literally zero risk by employing the developer in this case.
If you want to treat us like doctors and lawyers, you'd better give us their salary, benefits, and social status after we put in 4-8 years becoming qualified to meet this new threshold. Of course that's not going to happen, so guess who benefits by switching the industry to professional licenses?
Except engineers who have PEs and FEs don't exactly have massive salaries. "Software Engineers" are paid EXTRAORDINARILY well, especially compared to the amount of effort needed for that salary.
I would put it the other way: PEs and FEs are wildly underpaid for their abilities.
They are paid at the market price for the low job-growth market they're in, unfortunately. It's the same story with mathematicians and physicists who become finance quants. The finance world pays much better.
> "Software Engineers" are paid EXTRAORDINARILY well, especially compared to the amount of effort needed for that salary.
Sometimes I feel weird that I've been paid six figures+ to glue an API to a JavaScript frontend, especially at my age. But that's just the current market.
As I noted in another comment, a "proper PE type thing" exists for Software Engineering. In fact, it's an actual PE exam since 2013. It's probably higher level than you had in mind though, if you were expecting a focus more on algorithms than software lifecycle?
Not all states offer the PE software engineering exam; Califorina and Washington, for example, do not. Moreover, the Fundamentals of Engineering exam, which is a prerequisite for becoming a PE contains topics most practicing programmers would never have encountered and the rest would barely remember if they had. (Thermodynamics? Differential equations? Really?)
I'd say that either the ACM or IEEE Computer Society needs to develop an equivalent certification process and lobby to have states adopt it for licensure.
> Engineers are hired to create business value, not to program things
So is every employee of every company. They create business value by doing what their role is. This is the point of a company, this is how it's always worked. The role of a programmer is to program things. So a programmer programs things, and that is what they are hired for.
Why do we constantly get blog posts discussing ridiculous semantics like this?
Sure, it might work for some companies, but that's so utterly unimportant. I'm a programmer, I tell people I'm a programmer, I'm paid to program business applications, and I'm happily employed and liked by my superiors and company. Clearly this line of thought also works fine.
So maybe the best advice is to just do what you do, call yourself whatever, and cut it with these self-important blog posts preaching your way to everyone else as though it's some holy advice on cracking the employment puzzle.
> Why do we constantly get blog posts discussing ridiculous semantics like this?
Because many people (especially early in their careers) don't understand that. I didn't. I was hired to program, so I'd program, but I had no idea what the connection was between my work and people sending the company money.
That sounds like a bigger issue--being oblivious to what your role is/how companies work. No amount of re-naming/re-titling yourself will fix that. A name is just a name; it's what you do that matters.
You should of course do what you believe is best for your situation.
Patrick's observations are still useful, though. The semantics aren't ridiculous. They're a very real distinction, and they matter...especially if you're looking to move into contracting/consulting. If you find yourself doing that, it helps if you can position yourself farther up the value chain. In this situation, it helps to be able to describe yourself who understands business, communicates well, and can talk to a customer, understand their problem, and solve it. Having the ability to understand a business's problems and create software to solve those problems can give you a pretty significant advantage.
But this means you're not a programmer. If you understand a business's problems and create software to solve those problems, you've already moved higher up in the ranks than a programmer, so of course, call yourself whatever your title is (architect, engineer, director, whatever).
Semantics matter. Especially when you're trying to sell something, such as your skill set. Ever had to lobby your idea or project to a non-technical decision maker? You can't whip out the technical jargon and explain in minute detail why your solution is obviously the correct one. The non-technical decision maker is going to gravitate toward the option that is wrapped in the most appealing narrative - hence the semantics.
That's great that your happily employed and are well established in your company. I'm not. And a big junk of the problem is because of what Patrick discusses in that post. I'm an engineer who was hired to work in what is perceived as a cost center. Because of that, many of my solutions to problems are only allowed to be half implemented or they slide lower and lower down the priority list as more urgent tasks come up. The only reason they're more urgent is because someone can directly tie them to making money. Telling someone you "program" things doesn't tell them what value you bring to the table.
I wish I'd read this post 5 years ago when it was published and I might not be in such a sticky situation.
> Ever had to lobby your idea or project to a non-technical decision maker?
This is actually my job; I'm an architect and I interface a programming team with non-technical superiors (I simplified my position previously to make a point).
Part of my spiel in talking to non-technical superiors is being straightforward and bullshit-free. If something's a program, I call it a program, not a solution, business lalaploo, schpleplipagan, or quilbilbalala wrapped in bacon. It's a program, and it's programmed by programmers who are hired to program and spend their time programming. My non-technical superiors cherish this directness and lack of semantically loaded garbage. They "gravitate" towards the most clear and well-put solution, and part of that is not to wrap it in any narrative whatsoever, but to tell them straight up what the situation is. By wrapping something in a narrative, and trying to make it seem more than it is, it starts sounding less like professionalism and more like philosophy, and you instantly set off my bullshit detectors (and those of my superiors too). It starts smelling of indirectness and ulterior motives.
And this goes the other way too--when hiring someone, I'm hiring a programmer. Not an artist or philosopher who can tell me what silly billy value they add to my company. I decide what value they add; if they add any at all, it's the value of the programs they program (don't take that the wrong way--this is a lot of value, and I appreciate it fully, but it's still programming programs--the programs are the vehicle with which they add value).
I'm at a rather large company and management doesn't understand enough about what they're doing to know exactly what provides value and what doesn't, much less who is providing that value. I'm guessing once a company reaches a certain size, a lot of that becomes illegible.
I prefer to be direct and as clear as possible, but that hasn't been what's gotten me results. I watched how others (more senior engineers) were able to influence decisions and found that they were some of the best bullshit artists I've ever seen. So I adapted how I communicated as much as possible without compromising my ethics. I'm leaving my company, hopefully to join a company more like yours.
Yeah, maybe I do lack some perspective having never worked for a truly giant company. My parents both work at massive banks (in technology, in fact, my dad has almost the same job as I do), and a lot of what they talk about is how much politics they have to do on a daily basis that has nothing to do with their job, but rather just appeasing golden retrievers with treats and belly rubs.
But then, this goes even further to show how every situation is different and there's no umbrella of advice that works for employment.
"Don't call yourself a programmer" is a very old one; it's why we have titles like "software engineer", "software developer" and so on; those are reactions to "programmer analyst" and old stuffy "IBM-mainframe-ish" titles of that sort. You might have easily heard that advice in 1990.
Do call yourself a programmer to regular people. :)
The ironic part is that for every engineer being outsourced there's a new project manager being hired. And managers aren't any profit centers either. So why is this then?
As a student doing his graduation internship in a large corporation, I'm starting to see these things in real life.
Is this going to be anywhere close to the norm? I'm starting to consider a nomadic lifestyle.
> (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)
Good grief, what a lovely offhand comment that is.
>95~99: Your equity grant is a lifechanging amount of money.
> 100: You worked at the next Google, and are rich beyond the dreams of avarice.
Wait, so 5% of tech employees with equity grants make either a "life-changing" amount of money or an effectively endless amount?? Wow-- That seems to be a very high estimate. I would have thought that MAYBE 0.5% end up with "life-changing" liquidity, and MAYBE 0.001% end up multi-multi-millionaires.
It doesn't matter whether you call yourself a programmer or an engineer. In the software industry there is no standard for titles. They have misused this right from the beginning.
I am more upset that technical people are always seen as resources. You might feel you are building a great product and contributing to the great good. In reality, you are just a tool for someone to make money. You are an expendable resource who can be replaced in no time.
The management does fear attrition and key people leaving, just because it is a problem for them and a risk for the business if key supporting people leave. It might give them a setback. But in reality the management in every company thinks that they can find some other guy with equivalent/better knowledge, experience and he can replace you.
I sometimes fear that when I turn 60 and look back and realize that so many X no. of nights I spent was only to realize that I was eventually replace by someone and the top management people made a hell lot of money by selling the company.
The headline misled me. The gist of the article is good.
Two of the article's main points are solid:
(1) On your resume and in interviews, talk about results more than technology. Instead of "I know Python" or even "I've used Python for five years," it's stronger to say, "I rewrote the company billing system, used by 100 people, saving $100,000 in licenses." Have bullet points like that on your resume. This advice first came to me from a book on making resumes, given to me by a friend who works as a recruiter. It's okay to mix in technical, of course. A good example is actually this Hacker News comment: https://news.ycombinator.com/item?id=8902739
(2) Don't neglect the human factor. Basically it boils down to trust. Put yourself in the employer's shoes for just a second. Hiring a new employee is a significant act of trust. It should come as no surprise. Have you ever said to yourself at work, "Wow, I really can see everything. I could really do a lot of damage, if I weren't such an upstanding citizen." Exactly. The problem I guess is that most people don't have the time and money to check you out as well as they should. So they resort to all manner of shortcuts, like: are you well-dressed, are you clean, are you polite --- or do you come across as someone building a bomb in their basement, or someone who might build a bomb at my company if I don't buy you the right monitors? Other shortcuts are prevalent, like: are you a friend or relative of someone I already trust?
Yes, this is all embarrassingly low-resolution instrumentation for indentifying a good employee. However, can you think of anything better? Maybe you can. If so, there's loads of money to be made. Just try not to make it scary, like trying to algorithmically score a person based on key words in their opus of tweets.
A lot of the comments seem to miss out on the basic premise which is:
Don't sell yourself to business by taking a technical approach. (I do programming).
It is much more effective if you approach business as
- I solve problem X
> Similarly, even though you might think Google sounds like a programmer-friendly company, there are programmers and then there’s the people who are closely tied to 1% improvements in AdWords click-through rates. (Hint: provably worth billions of dollars.)
It's hard to quantify the benefits your work brings to a company. Probably worth the effort, but for most jobs it's going to involve some time with pen and paper and some imagination regarding counterfactuals.
> I recently stumbled across a web-page from the guy whose professional bio is “wrote the backend billing code that 97% of Google’s revenue passes through.” He’s now an angel investor (a polite synonym for “rich”).
Wait. Yes there's a number in there but it's not one that attempts to quantify benefit. So is this guy just saying you need to quote a number (preferably high), doesn't matter what it relates to?
150 comments
[ 2.7 ms ] story [ 246 ms ] threadIf you read nothing else, read: Engineers are hired to create business value, not to program things
I think a good follow up of "don't call yourself a programmer" is "Don't look for a job". The moment you start looking for a job, you're pretty much that "Java programmer" again. Somehow, the people I meet who can't find a job are those who are looking, while those who speak about their employment in literally any other way than "looking for a job" never seem to have a problem. I don't know exactly which way the causation link works (maybe people who are good at getting jobs are privileged enough to not have to think about it in that way), but I'm pretty sure that the word 'job' and mental model associated with it is not optimal.
It's hard to overcome though. In a previous role, I was the main UI dev on a rewrite of a top 10 ecommerce site's checkout process and also had a lead role in designing the checkout API that handles $billions in revenue a year. But it was really hard to get myself to add any of that to my resume or linkedin profile. Like I was worried about someone somehow calling me on it, even though it's completely true.
Of course, now that I've written that, I feel like it may have more to do with impostor syndrome than modesty.
Design is.
(Not just industrial design looks -- the whole design of the product as a coherent whole, including the design of the electronics, ecosystem, etc).
What he writes will be outdated when Google outsources their Search engine, or Facebook outsources their social graph machinery,
Manufacturing is a cost center, not a profit center.
Apple probably sees design, marketing, and sales as its profit centers. I don't know about Apple specifically, but some companies I've dealt with view manufacturing as a black box: input design and money, receive widgets in return. Good design enables marketing, and marketing enables sales, so the design->marketng->sales pipeline is viewed as the profit center.
A lot of companies, even software companies, see their developers as a similar black box: input ideas and money, receive software you can market and sell. Depending on a company's culture, it can be hard for developers to shift this perception. In some cases, I'm not even sure it is the wrong perception. In SaaS companies, it is easier to tie the work of developers to the revenue it helps generate than in an enterprise software company where selling is going to require a professional, high touch sales force regardless of how good the software is.
They're correct; it's just that the rule is flouted to the point of non-existence in tech.
https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
If tech companies were breaking the law, someone would be suing.
I wasn't referring to tech companies, but individuals calling themselves an engineer, so I don't think that applies.
But the point of the article is to not pigeonhole yourself. Don't be that guy who wrote that library, or the guy who maintains that app. Be the guy who brings value to the business. Be the guy who is considered an asset no matter what role they have, because you are working towards the goals of the business. Be the guy who knows when to say, "Yes, I can code that, but we can buy it just as cheaply, and let me focus on more important details of our business."
Uh no. I code, that's what I do. I'm fine with being laid off if that's not creating value. I can code somewhere else.
If you go into a non-engineering role, you are sacrificing your engineering career for temporary survival at your current job. The next engineering job you apply to wont probably like that you haven't done SWE work for whatever amount of time. Just pull off the bandaid and get a new job.
I'm an engineer. I want to be good at engineering. I'm not interested in the rest of it. It's not my job to make sure the engineering tasks line up with business success. My job is making the math and the code work. Division of labor. I don't want any other role. If engineers aren't valued I'll go somewhere where they are. There are lots of engineers creating value all over the place. There's lots of opportunities out there, there's no reason to have to sell yourself if your skills don't.
As an engineer it's easy to think "yeah, well I write good code.." but in my experience you will never be able to adequately demonstrate that to a potential employer during the interview process.
Being "interested in the rest of it" makes you a better engineer. Indeed, there's an argument to be made that that's part of what makes you an engineer.
How do you know whether you're creating value if you don't care to know what's valuable? How do you expect to be able to make yourself worth hiring if you don't know and won't learn how to make your paycheck worth signing? How do you intend to build tools that make people's lives better if you can't be bothered to understand what they need?
If all you do is code I wouldn't consider you an engineer.
> Engineers design materials, structures, and systems while considering the limitations imposed by practicality, regulation, safety, and cost.
* don't call yourself a programmer, you are a revenue-enhancing solution provider
* especially don't call yourself an X programmer, you will use whatever tool is necessary to complete the project and provide value
* don't look for a job, this shows that you're weak. Let the jobs come to you.
* keep yourself current with the latest frameworks and languages to prove that you can adapt to new challenges
* having at least one but ideally more open source projects on github proves that you have passion
* make sure you're a culture fit. Do go to the company parking lot beforehand to see what others wear.
* wear nice clothes, brush your teeth and eat your veggies
* <insert your own here>
After doing all of this you will probably succeed in avoiding having your job outsourced or having that promotion given to someone that's an even bigger bulshitter than you. Congratulations! Now you only need to have some minor plastic surgery done and learn a few recent cultural references in order to not make your colleagues uncomfortable.
You are well on your way to become the perfect solution provider citizen!
Real engineers have certification: you know, that thing that indicates that you can actually do your job worth a damn. What do programmers say whenever the topic of industry certification is brought up? Usually, furious opposition.
Real engineers have accountability: engineers in a lot of other industries can be civilly or even criminally liable if their broken shit hurts somebody. What do programmers say whenever the topic of accountability for broken software is brought up? Usually, furious opposition.
Real engineers have unions. You know, that thing that keeps your labor from being exploited by-- just to give some hypothetical examples-- intentionally confusing and exploitative equity renumerance, or floods of H1-B workers. I shouldn't even have to tell you what the attitude towards most programmers is to unions, at least in America.
And whenever the topic of certification, or accountability, or unions, is brought up in the context of our discipline, the response is almost invariably, "Well, it's different for us, because $REASONS". Okay, fine, it's different for us, but then we shouldn't call ourselves engineers, because it's clearly a category error.
What would you put in software certification? If you focus on high-end CompSci stuff, it won't be relevant for the 99% who spend their careers building CRUD apps. If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
I agree that there could be industry certification on topics like security and perhaps accessibility. But on everything else, the answers depend on so many factors, they can't be certified in a meaningful way.
Also, some of the best software engineers I know don't have certification because they struggle with exams. The ability to pass an exam doesn't make you a better engineer.
Certification is nice in theory, but in practice would probably lead to worse results.
I call myself a software engineer because it's what managers call me. As long as I don't claim to be able to build a bridge across the River Thames, I don't see the problem.
It's to give the world hard proof that you actually UNDERSTAND what is happening and allows you to actually accept responsibility to create things that may actually affect peoples lives. Sure its useless if all you do is work on a react/angular app, but not all software is your standard CRUD app.
But there's no clear line where an app stops being CRUD and starts being something more, so there's no clear line where you stop needing a CRUD programmer and start needing a software engineer.
There are some that clearly need certification, and often that is an explicit requirement of the job.
Just don't get too hung up on the job title. Managers want to believe their software is so complicated that they need a software engineer to build it. I'm happy to go along with their delusions if they pay me.
As a "guy who writes code" - call me whatever you want, i could probably give myself a fancy title and get away with it, but I am one of the very successful (When compared to the 99%) people who didn't finish school but managed to get by in the tech industry very comfortably. Life is already great, perhaps I just don't deserve to get everything my way.
I don't use "software engineer" as an ego thing, but because it communicates better the variety of knowledge I have to people that barely understand how to turn their computer on. I get better pay, my employer is happy, everybody wins.
Engineer is not a guy putting things together on an assembly line. Engineer needs to understand things that are base for his/her field.
> If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
My tools that are dozen years old work just fine, thank you very much. And they work faster, more transparently, and more reliably than most of modern buzz, if we're at that.
Really, the ideal system is self serving. You create a framework of professionals that self-govern. The Professionals appointed/elected to the governing body are responsible for ensuring the certification is relevant to the profession. I somewhat prefer the mentorship program over testing individuals on knowledge in their domain because your mentor(s) will be a better judge that you're understanding concepts, regulations, rules, and needs better than any exam will test for. Like you said, knowledge that I apply on my career is very different from knowledge you apply in yours.
Another thing that I want to say though is that I don't feel certification is necessary in software unless you're in a position that carries potential harm to a person's safety/wellbeing. There's a few exceptions to what that entails exactly but that's not really the point of this discussion. Generally speaking, I don't want someone with a layman's understanding of code to be programming things where a person can lose their life due to an oversight. In the same way that Professional Engineers in Civil, Mechanical, etc. use their professional seal to say that "my specs meet all relevant modern standards of safety/design/etc", I want software engineers programming that medical device or safety equipment have the same accountability. Currently there isn't an international recognition of "Software Engineer" as a title to say who is working on that device has been vouched for professionally.
There is a difference here in that someone working on a medical device isn't directly offering their services to the public, and the work-product is subject to external testing and oversight.
Hm... ok, I'm not sure I buy that. How are you defining "best"? I suppose I can accept that there may be a handful of people (worldwide) who can produce amazing software but are somehow unable to memorize and regurgitate facts, in the same sense that there are people in the world who can recite all the digits of pi but can't tie their own shoelaces - but I have a hard time believing that such people are very, very rare.
I see nothing wrong with someone calling themselves a software engineer that has both training (a CS degree for example) and experience (a few years) working in software development.
https://engineers.texas.gov/software.html
2014: 6 people took the test and 2 passed.
2015: 5 people took the test and 2 passed.
2016: 3 people took the test and 2 passed.
Only California has more programmers than Texas, see [2], and it appears that there are 6 Professional Engineers at most in Texas in the field of Software Engineering out of over 20,000 programmers.
My conclusion is that the title of PE in Software Engineering is currently pretty meaningless in the US.
[1] https://engineers.texas.gov/exam_passfail.htm
[2] http://www.bls.gov/oes/current/oes151131.htm
> ABET (the engineering accreditation society in the US), doesn't have "Software Engineering" as a valid discipline.
Which can be true or false independently of how meaningful the title is.
* Demand, since it is a new exam very few companies will be looking for a PE in software engineering.
* Supply, it's not just taking the test (starting with the FE) but you also need to have worked under a PE in the field (hah!) or had relevant experience to waive that requirement (this is a lot more vague and determined by the state). I would wager that most with relevant experience in the field are also not wanting to bust ass to study for a PE exam that no employers are demanding.
I'll be interested to see how long it takes for this to be more common. When I graduated (computer engineering) the consensus was that unless we knew our job would require a PE in the future that we didn't bother even taking the FE exam.
[0] and probably also offering "engineering" services but I'm not sure of the extent there
No, it's like professional soccer teams saying "I won't hire anybody who the USSF didn't say is a 'soccer player' because they have a good track record of establishing credentials and I trust their judgment".
Directly from wikipedia: In 1960, the Conference of Engineering Societies of Western Europe and the United States of America defined "professional engineer" as follows:
A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character. It requires the exercise of original thought and judgement and the ability to supervise the technical and administrative work of others. His/her education will have been such as to make him/her capable of closely and continuously following progress in his/her branch of engineering science by consulting newly published works on a worldwide basis, assimilating such information and applying it independently. He/she is thus placed in a position to make contributions to the development of engineering science or its applications. His/her education and training will have been such that he/she will have acquired a broad and general appreciation of the engineering sciences as well as thorough insight into the special features of his/her own branch. In due time he/she will be able to give authoritative technical advice and to assume responsibility for the direction of important tasks in his/her branch.
I don't see anything about unions in there
Basically, what defines a "real engineer" has pretty much nothing to do with engineering? I'd rather define engineers as people who have the skill and know how to engineer.
Why do I keep seeing people comment without reading the article at all...
I hate being called a programmer, am okay with developer, and call(ed) myself a software engineer, and that's why my title said as well. I wasn't the director of programming, and I wasn't running a team of programmers. I ran the software engineering team and I hired software engineers.
In my mind, they're not interchangeable terms and have specific meanings. A programmer is someone who can write code, cobble together applications in a generally slapdash fashion, and does not apply a lot of creativity or thought to the how's and why's of what they are doing. They are the front end web dev who can't write pure JavaScript and have to use jQuery and a bajillion other includes just because they don't know how or care about the implications.
A developer pays some attention and care, has a reason why they may have made certain decisions, and is generally thoughtful about their core areas of knowledge. Maybe they're not as thorough, have a more narrow window of experience, or generally don't care about 'those other things' like networking, operating systems, protocols, etc.
A software engineer knows about OSI, the types of protocols in use by their application, the pros and cons of various libraries, and has a reason that can be backed up with at least some empirical evidence for any of the choices they make. They step back and look at the problem they're solving as a whole instead of piecemeal, and they're generally not shortsighted. They apply rigor, experience, and research to all phases of what they're working on.
We were all programmers and developers, some of us get to software engineers if we want- but it's really about the rigor and discipline you apply to your craft.
I agree that the fundamental aspect is the accountability, however unions don't mean anything for the quality of your work, and there are ways to certify specific areas of knowledge already.
You must be a C/C++ guy :)
Some engineering fields have all those things you describe but it is usually because there is a high degree of physical risk to the public, like structural engineers for example.
Mechanical and Electrical engineers, for example, at most companies are hired without any such certifications, unions, oversight, or any of what you've mentioned. I have a degree in EE and CS and have worked in both fields doing everything from IC design to app development and the hiring process, oversight, etc has been the same in almost every case - no membership or union required. I have friends who work as ME, Chemists, physicists, etc and the same is true for all of them except in the exceptional cases where they are working on a medical device or something.
Really all those things you mention at most companies for most fields of engineering come down the the company culture itself and the technical leadership at those companies.
The really funny thing about your take is that in most cases I find that high level software developers have a much stronger cult of engineering excellence that any of those other fields. If you saw the "process" most EE's used to ensure high quality engineering at large companies like Intel you would be horrified. And definitely don't ask those EE guys to write any code, it will almost certainly be terrible.
It's not a requirement for ME and EE, but it is a universally recognized certification. PE-licensed engineers often enjoy better employment prospects.
(FYI, there is PE exam for software. The difference is: it's not widely know in the industry.)
I tried to see if there was an opportunity for an engineering mentor at my job (One of the big four) and I was unable to get anywhere. It seems that it is better for our job prospects to get a job at a prestigious/interesting company and gain experience there than try to go through the licensing process.
[1]:http://ncees.org/licensure/
Yeah, don't do this in Canada, or the professional engineers association can come after you. Only certified members of an engineers professional association can use the title.
To be clear, it is illegal, for example, to pass around business cards that say 'Software Engineer' if you're not certified.
As an amusing example, in the province of Ontario, people with the Microsoft Certified Systems Engineer certification are allowed to use the title 'MCSE', but not its expansion, because it contains the word 'Engineer'.
However, you are always allowed to state your degree, so you can say, {name}, B. Eng., or M. Eng., as the case may be.
*At least, in Quebec and Ontario - the legislation is province-scoped, I assume other provinces are similar.
Coming from a US perspective, I feel like "engineer" on its own is a descriptive word. "Professional Engineer" is a trademarked title, and that seems reasonable. Do I have certification as a PE? No. Do I think it's reasonable to describe what I do as software engineering? Yes. To me, it implies that I take part in planning, designing, implementing, supporting, and retiring software. "Programmer" connotes that I took someone else's design, wrote to that spec, and handed the results off to someone else, rather than taking part in the entire lifecycle.
In addition to the points you make, real certification (as opposed to a four year degree, which anyone willing to go into debt can get) would simplify interviewing and reduce the "whiteboard hazing" and "throw darts at a dart board" methods we use today for finding good candidates. Organization would help fight for a proper career path for programmers, rather than having to, as an individual, constantly negotiate and hop from one employer to another in order to advance.
Well, I admire your optimism, and as much as I wish there were professional licensing for software professionals, I doubt that any licensing exam could ever be so rigorous that at least a few charlatans wouldn't be able to squeak through it.
> would simplify interviewing and reduce the "whiteboard hazing"
I doubt it. If a certification is too specific it'll exclude an enormous amount of engineers. Make it too broad and then companies will still have to do the same interviews they do now to verify that a person is a good fit for the specific job opening they want to fill.
I'm eager to hear your proposal on a certification method that doesn't exclude wide swaths of existing and future engineers based on your specific definition of what a software engineer is and isn't, but at the same time is specific enough that having the certification actually means something to other people.
Most likely it is because a great many programmers without a formal college education or with a non-CS college education think that certification might be used to demote them to second-class citizens. And, without commenting on the rightness or wrongness of it, they wouldn't necessarily be incorrect about that either; such an exam would most likely have a strong focus on CS topics.
That's literally my job right now. If I could claim the title of Doctor I'd totally be for certification (but for purely, very selfish reasons).
my response to this is simple: do you think that words matter? If so, which word do you think is most effective in communicating with people outside of the field?
there's room for people to come up with radically different answers to those questions, but my answer is that "Software Engineer" matters when communicating with non-programmers. When talking shop with a fellow practicioner it doesn't matter much what word you use. This is just about communication with the outside.
That's great if things work that way in other countries. But in the States, things work differently (in the software industry, at least). And like it or not, are unlikely to change (any more than this country is likely to shift over to the metric system) anytime soon.
And unfortunately the term "programmer", as a resume heading, has come to be laden with negative baggage in various ways (as detailed in the original article). So in practical terms, you are 1000% better off calling yourself an engineer or developer (rather than a "programmer") in the U.S. at least.
I'm pretty sure that's not true, and in fact one of the distinctions about a professional is that he doesn't belong to a union: he is both worker and management.
Plus it's baked into the title of "the Art of Computer Programming" by Donald Knuth. How many people can really say they have mastered that art? It's hard to believe there's any qualification more worth striving for or harder to achieve.
Programmers have a lot of engineering work supporting them in different ways and sometimes they do actual computational engineering. I don't have a problem with calling myself a programmer. Patrick M does because he wants to translate his work into the language of corporate and marketing communication because he thinks this will make him more valuable. I'm not sure that's a good strategy except to create a kind of odd cloud around what he's doing. Programming is not so mysterious to management anymore. They know it's valuable. Those that don't, well, I'm not sure you want to work for them anyway.
But customer demand is only useful if you can turn the demand into a sale and a happy customer. Measuring the conversion of an interested user to a customer is how you measure return on investment for features.
If what you did meant an increase in revenue from those customers, then it is fair to say it drove revenue.
If you want to treat us like doctors and lawyers, you'd better give us their salary, benefits, and social status after we put in 4-8 years becoming qualified to meet this new threshold. Of course that's not going to happen, so guess who benefits by switching the industry to professional licenses?
They are paid at the market price for the low job-growth market they're in, unfortunately. It's the same story with mathematicians and physicists who become finance quants. The finance world pays much better.
Sometimes I feel weird that I've been paid six figures+ to glue an API to a JavaScript frontend, especially at my age. But that's just the current market.
Software engineering topics:
http://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pdf
Electrical Engineering -> Computer Engineering topics:
http://ncees.org/wp-content/uploads/2015/07/PE-Ele-Computer-...
I'd say that either the ACM or IEEE Computer Society needs to develop an equivalent certification process and lobby to have states adopt it for licensure.
So is every employee of every company. They create business value by doing what their role is. This is the point of a company, this is how it's always worked. The role of a programmer is to program things. So a programmer programs things, and that is what they are hired for.
Why do we constantly get blog posts discussing ridiculous semantics like this?
Sure, it might work for some companies, but that's so utterly unimportant. I'm a programmer, I tell people I'm a programmer, I'm paid to program business applications, and I'm happily employed and liked by my superiors and company. Clearly this line of thought also works fine.
So maybe the best advice is to just do what you do, call yourself whatever, and cut it with these self-important blog posts preaching your way to everyone else as though it's some holy advice on cracking the employment puzzle.
Because many people (especially early in their careers) don't understand that. I didn't. I was hired to program, so I'd program, but I had no idea what the connection was between my work and people sending the company money.
Patrick's observations are still useful, though. The semantics aren't ridiculous. They're a very real distinction, and they matter...especially if you're looking to move into contracting/consulting. If you find yourself doing that, it helps if you can position yourself farther up the value chain. In this situation, it helps to be able to describe yourself who understands business, communicates well, and can talk to a customer, understand their problem, and solve it. Having the ability to understand a business's problems and create software to solve those problems can give you a pretty significant advantage.
That's great that your happily employed and are well established in your company. I'm not. And a big junk of the problem is because of what Patrick discusses in that post. I'm an engineer who was hired to work in what is perceived as a cost center. Because of that, many of my solutions to problems are only allowed to be half implemented or they slide lower and lower down the priority list as more urgent tasks come up. The only reason they're more urgent is because someone can directly tie them to making money. Telling someone you "program" things doesn't tell them what value you bring to the table.
I wish I'd read this post 5 years ago when it was published and I might not be in such a sticky situation.
This is actually my job; I'm an architect and I interface a programming team with non-technical superiors (I simplified my position previously to make a point).
Part of my spiel in talking to non-technical superiors is being straightforward and bullshit-free. If something's a program, I call it a program, not a solution, business lalaploo, schpleplipagan, or quilbilbalala wrapped in bacon. It's a program, and it's programmed by programmers who are hired to program and spend their time programming. My non-technical superiors cherish this directness and lack of semantically loaded garbage. They "gravitate" towards the most clear and well-put solution, and part of that is not to wrap it in any narrative whatsoever, but to tell them straight up what the situation is. By wrapping something in a narrative, and trying to make it seem more than it is, it starts sounding less like professionalism and more like philosophy, and you instantly set off my bullshit detectors (and those of my superiors too). It starts smelling of indirectness and ulterior motives.
And this goes the other way too--when hiring someone, I'm hiring a programmer. Not an artist or philosopher who can tell me what silly billy value they add to my company. I decide what value they add; if they add any at all, it's the value of the programs they program (don't take that the wrong way--this is a lot of value, and I appreciate it fully, but it's still programming programs--the programs are the vehicle with which they add value).
I prefer to be direct and as clear as possible, but that hasn't been what's gotten me results. I watched how others (more senior engineers) were able to influence decisions and found that they were some of the best bullshit artists I've ever seen. So I adapted how I communicated as much as possible without compromising my ethics. I'm leaving my company, hopefully to join a company more like yours.
Patrick's advice hit pretty close to home for me.
But then, this goes even further to show how every situation is different and there's no umbrella of advice that works for employment.
Do call yourself a programmer to regular people. :)
The ironic part is that for every engineer being outsourced there's a new project manager being hired. And managers aren't any profit centers either. So why is this then?
Good grief, what a lovely offhand comment that is.
> 100: You worked at the next Google, and are rich beyond the dreams of avarice.
Wait, so 5% of tech employees with equity grants make either a "life-changing" amount of money or an effectively endless amount?? Wow-- That seems to be a very high estimate. I would have thought that MAYBE 0.5% end up with "life-changing" liquidity, and MAYBE 0.001% end up multi-multi-millionaires.
> Perceptive readers will note that 100 does not actually show up on a d100 or rand(100).
That makes the whole point ;)
I am more upset that technical people are always seen as resources. You might feel you are building a great product and contributing to the great good. In reality, you are just a tool for someone to make money. You are an expendable resource who can be replaced in no time.
The management does fear attrition and key people leaving, just because it is a problem for them and a risk for the business if key supporting people leave. It might give them a setback. But in reality the management in every company thinks that they can find some other guy with equivalent/better knowledge, experience and he can replace you.
I sometimes fear that when I turn 60 and look back and realize that so many X no. of nights I spent was only to realize that I was eventually replace by someone and the top management people made a hell lot of money by selling the company.
Did you read the article? He does not suggest calling yourself an engineer as an alternative to calling yourself a programmer
Two of the article's main points are solid:
(1) On your resume and in interviews, talk about results more than technology. Instead of "I know Python" or even "I've used Python for five years," it's stronger to say, "I rewrote the company billing system, used by 100 people, saving $100,000 in licenses." Have bullet points like that on your resume. This advice first came to me from a book on making resumes, given to me by a friend who works as a recruiter. It's okay to mix in technical, of course. A good example is actually this Hacker News comment: https://news.ycombinator.com/item?id=8902739
(2) Don't neglect the human factor. Basically it boils down to trust. Put yourself in the employer's shoes for just a second. Hiring a new employee is a significant act of trust. It should come as no surprise. Have you ever said to yourself at work, "Wow, I really can see everything. I could really do a lot of damage, if I weren't such an upstanding citizen." Exactly. The problem I guess is that most people don't have the time and money to check you out as well as they should. So they resort to all manner of shortcuts, like: are you well-dressed, are you clean, are you polite --- or do you come across as someone building a bomb in their basement, or someone who might build a bomb at my company if I don't buy you the right monitors? Other shortcuts are prevalent, like: are you a friend or relative of someone I already trust?
Yes, this is all embarrassingly low-resolution instrumentation for indentifying a good employee. However, can you think of anything better? Maybe you can. If so, there's loads of money to be made. Just try not to make it scary, like trying to algorithmically score a person based on key words in their opus of tweets.
It is much more effective if you approach business as - I solve problem X
It's hard to quantify the benefits your work brings to a company. Probably worth the effort, but for most jobs it's going to involve some time with pen and paper and some imagination regarding counterfactuals.
> I recently stumbled across a web-page from the guy whose professional bio is “wrote the backend billing code that 97% of Google’s revenue passes through.” He’s now an angel investor (a polite synonym for “rich”).
Wait. Yes there's a number in there but it's not one that attempts to quantify benefit. So is this guy just saying you need to quote a number (preferably high), doesn't matter what it relates to?