Don't Call Yourself A Programmer, And Other Career Advice (2011)
kalzumeus.com
kalzumeus.com
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.
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.
> 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.
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.
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.
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!
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.
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.
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.
> 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 ;)
Good grief, what a lovely offhand comment that is.
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.
Do call yourself a programmer to regular people. :)
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
If you read nothing else, read: Engineers are hired to create business value, not to program things
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.
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?
It is much more effective if you approach business as - I solve problem X
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?
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.