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.
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.
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.
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.
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.
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.
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.
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?
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!
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.
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.
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.
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.
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.
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.
> "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.
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.
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."
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!
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?
> 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.
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.
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.
> 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.
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.
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).
>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.
> (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.
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 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.
"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. :)
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.
> 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?
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.
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
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?
[+] [-] Analemma_|9 years ago|reply
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.
[+] [-] eagsalazar2|9 years ago|reply
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.
[+] [-] KaiP|9 years ago|reply
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
[+] [-] olalonde|9 years ago|reply
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.
[+] [-] shawkinaw|9 years ago|reply
[+] [-] nickbauman|9 years ago|reply
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.
[+] [-] manyxcxi|9 years ago|reply
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.
[+] [-] blowski|9 years ago|reply
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.
[+] [-] ryanolsonx|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] grb423|9 years ago|reply
[+] [-] ryandrake|9 years ago|reply
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.
[+] [-] lizardking|9 years ago|reply
[+] [-] ritchiea|9 years ago|reply
[+] [-] emodendroket|9 years ago|reply
[+] [-] zeveb|9 years ago|reply
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.
[+] [-] hodgesrm|9 years ago|reply
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.
[+] [-] kafkaesq|9 years ago|reply
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.
[+] [-] metaphorm|9 years ago|reply
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.
[+] [-] duaneb|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] strictnein|9 years ago|reply
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.
[+] [-] mevile|9 years ago|reply
[+] [-] codingdave|9 years ago|reply
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."
[+] [-] blub|9 years ago|reply
* 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!
[+] [-] vvanders|9 years ago|reply
[+] [-] Xantier|9 years ago|reply
[+] [-] zodiac|9 years ago|reply
[+] [-] capote|9 years ago|reply
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.
[+] [-] analogwzrd|9 years ago|reply
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.
[+] [-] rpeden|9 years ago|reply
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.
[+] [-] AnimalMuppet|9 years ago|reply
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.
[+] [-] combatentropy|9 years ago|reply
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.
[+] [-] sixhobbits|9 years ago|reply
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.
[+] [-] throw_away_777|9 years ago|reply
[+] [-] ryandrake|9 years ago|reply
> 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.
[+] [-] indubitably|9 years ago|reply
Good grief, what a lovely offhand comment that is.
[+] [-] econner|9 years ago|reply
[+] [-] NikolaeVarius|9 years ago|reply
[+] [-] kazinator|9 years ago|reply
Do call yourself a programmer to regular people. :)
[+] [-] rajeshp1986|9 years ago|reply
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.
[+] [-] bluetwo|9 years ago|reply
If you read nothing else, read: Engineers are hired to create business value, not to program things
[+] [-] Animats|9 years ago|reply
[+] [-] alimw|9 years ago|reply
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?
[+] [-] RandomInteger4|9 years ago|reply
[+] [-] Fang_|9 years ago|reply
[+] [-] kayman|9 years ago|reply
It is much more effective if you approach business as - I solve problem X
[+] [-] Puts|9 years ago|reply
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?
[+] [-] kzisme|9 years ago|reply