Don't call yourself a programmer, and other career advice (2011) | Hacker News Reader

Don't call yourself a programmer, and other career advice (2011)

kalzumeus.com

245 pointsjckahn162 comments

This whole article is great advice for playing the career game, or “how to fit in and not get bullied at school”. Note that it comes at a cost, and that cost may or may not be worth it to you.

Note also that playing a game for a long time you forget that you are playing a game, and you start incorporating the rules of the game into your mind. Some people are more resistant to this effect than others, and some people share the same values in the first place. Others dislike who they become and either quit or become resentful.

A big pile of money looks like the best thing in the world to a college grad. Playing a game you aren’t passionate about can be a worthwhile compromise, especially if you don’t have much financial safety. But never let anyone else tell you what game to play, that is your choice alone.

If you have the privilege to choose what game to play, I recommend picking not by the rewards of the game – but based on how you like the rules of the game.

I’m willing to play the game as a survival mechanism. I’m not in tech (professionally) because of passion. I’m in it to survive and solve problems that having money can solve.

I make open source software and give it away for free in my spare time because of passion. The fact that my job and my hobby are very similar is merely incidental.

Great post overall, and great advice on picking your game.

What I would add is: sometimes the thing which you want to do can't be done without some engagement in a game you don't like. It doesn't mean you have to give in and lose yourself entirely to the game, but you need at least pay enough attention to understand what's going on. The world is full of gatekeepers, often where you least expect it. Trying to avoid that reality can sometimes lead you to a worse place than just sucking it up and putting on a smile to get where you want to be.

The article finishes with:

  At the end of the day, your life happiness will not be dominated by your career.  Either talk to older people or trust the social scientists who have: family, faith, hobbies, etc etc generally swamp career achievements and money in terms of things which actually produce happiness.  Optimize appropriately.  Your career is important, and right now it might seem like the most important thing in your life, but odds are that is not what you’ll believe forever.  Work to live, don’t live to work.

I paraphrase the article as: (1) these are the real rules, (2) you must know and internalise these rules because playing the game is compulsory if you “choose” to work, (3) you must not fall for fairytales.

> playing the career game

The audience for this article is engineering graduates starting a career, not artists searching for meaning. “Programmer” is right there in the title. Whether you want to play the career game or not, it is one of the few games most of us will play, unfortunately. Totally agree that the game has its compromises.

I’m on the wrong side of 60 and have loved being a programmer for 4 decades. I don’t mind saying it’s a substantial part of my identity.

By wrong side I assume you mean you’re my age (30). We should all be lucky enough to acquire the wisdom of a 60+ year old.

Made me smile. You’re very kind, neighbor (Redmond representing).

I think this used to be true when a single blue collar income was enough to provide your family with food and shelter and a bit extra. Today if you're not earning an above average wage you just can't have the family, hobbies, etc. Life got a lot more expensive.

The pursuit of money isn't what makes people happy, but a lack of money definitely stops people being happy.

> The audience for this article is engineering graduates starting a career, not artists searching for meaning.

Totally agree, I understand how it could sound irrelevant or pretentious. There are a couple of reasons why I wrote this comment, and I assure you it’s all in good spirit:

First, some young people who love programming don’t want to play the career came, and there is space for them as well. I read the article as “you must play to get anywhere” (my interpretation). You can do your thing, either alone or at a company, and simply not care.

Secondly, I know many who have more money than they could dream of earlier in their lives, but they’ve readjusted and moved the goalpost, and keep grinding seemingly because of peer pressure and habit alone. Some of them are miserable for no reason.

Third, working in order to play another game that you really like (family, hobbies, travel) is perfectly fine. Many people in my generation think that you must play all games at once, and they get exhausted. But no need – not giving a shit is sometimes the highest virtue.

Playing the game is an important life skill. Go for that pile of money early. Compound interest over years means it can make the difference between just making ends meet for the rest of your life, and actually having something substantial to retire on. Apply to FAANG or whatever it is these days if you're smart enough. Prove you're smart enough by grinding leetcode and doing mock interviews. Don't faff about with homebrew game consoles or microcontroller things, things of that nature unless work demands it. Focus on GPGPU and open source FPGAs. Not quantum computing, though, it looks like that might be another time/money/energy sink like crypto. (Reconsider it if I'm proven wrong.)

Don't get distracted by the Lisp lotus-eaters. The future will be built on doing massive array-based computation as fast as possible, as parallel as possible, using as little power as possible.

Knuckle down and do the high-paying work early on, and possibilities will open up as to what game to play in your 30s, 40s, and beyond. Play the tech bohemian in your 20s, and you may find yourself struggling in later life.

> and you may find yourself struggling in later life.

Generally you don't get to pick no struggles. If you play the tech game real hard in your 20s, you might have no friends in your 30s, and your struggle might manifest in "Ask HN: How do you make friends after 30?" type posts.

You can always push personal value down the line until you don't remember what it is you truly value. If that's only money and arbitrary success, then great, spend your 20s doing that.

Having played the open source tech bohemian in my 20s I think it was fine. While I earned a fraction of what I earned later in Silicon Valley it paid better than most of my contemporaries and through it I met a bunch of interesting people from around the world and became a much better programmer than I’d otherwise have been.

Maybe. I've never hired for FAANGs but from the other side of the interview table, I'd much sooner hire someone overflowing with energy and enthusiasm for homebrew game consoles or hacking a TI-83 calculator, than someone who has practiced the right exercises but has no passion for the work, doesn't remember when they stopped loving tech, and would have pursued a different major if the big bucks were elsewhere.

It's not hard to tell.

"We are what we pretend to be, so we must be careful what we pretend to be." - Kurt Vonnegut

"I pretended to be somebody I wanted to be until finally I became that person. Or he became me." - Cary Grant

When I became a dad I started making 'dad' jokes sarcastically. Now I make them and I don't even notice. So yes, beware.

It works in reverse, too. I've been gleefully making dad jokes forever and look where that got me.

>> If you have the privilege to choose what game to play, I recommend picking not by the rewards of the game – but based on how you like the rules of the game.

It's kinda both though isn't it? Sure we all want to play the game with the "right rules", but at the same time I also care deeply about the rewards - I want time with the family, I don't want to worry about money every night, and so on.

But I agree, rules first. You can live on less money, but bad jobs destroy the soul.

I would add this. Wherever you end up, understand that there are rules. They may not be intuitive. They may not be logical. But they exist. Don't assume. If you don't like the rules, or can't do the rules, change the game - you're not going to change the rules (and fighting to do so is exhausting.)

For reference, I've spent my whole career building boring Crud apps in a language you've never heard of. It's not sexy, but it's given me a great life - more than I would have hoped for.

> For reference, I've spent my whole career building boring Crud apps in a language you've never heard of.

Well now I have to guess. ColdFusion?

I feel like a lot of programmers on here have probably heard of ColdFusion. Allaire (and Macromedia after they bought them) built one of the best IDEs back in the day. It was a strong competitor to Komodo.

ColdFusion is a global household name compared to what I use :)

Fine, keep your secrets.

PowerBuilder?

> It's kinda both though isn't it?

You spotted my intentional hyperbole :) I wanted to draw attention to it because it’s underrated, but you’re totally right that it’s always a compromise.

> Wherever you end up, understand that there are rules.

Absolutely. And not only social, but inherent rules in the domain you’re working. For instance, math research has more discontinuous progress than building crud apps.

You both have a point. For my own career I found the advice of Oliver Burkeman helpful, who put it in a very apt and actionable sentence:

> When stumped by a life choice, choose “enlargement” over happiness.

The good part is that there‘s still a lot of jobs out there who both enlarge you and make good money. They‘re just harder to find.

https://www.theguardian.com/lifeandstyle/2020/sep/04/oliver-...

The main past threads appear to be:

Don't Call Yourself A Programmer, And Other Career Advice (2011) - https://news.ycombinator.com/item?id=28234937 - Aug 2021 (89 comments)

Don't Call Yourself a Programmer, and Other Career Advice (2011) - https://news.ycombinator.com/item?id=21303181 - Oct 2019 (307 comments)

Don't Call Yourself A Programmer, And Other Career Advice (2011) - https://news.ycombinator.com/item?id=12548043 - Sept 2016 (147 comments)

Don't call yourself a programmer (2011) - https://news.ycombinator.com/item?id=9015160 - Feb 2015 (84 comments)

Don't Call Yourself A Programmer, And Other Career Advice (2011) - https://news.ycombinator.com/item?id=8147008 - Aug 2014 (44 comments)

Dont call yourself a programmer (2011) - https://news.ycombinator.com/item?id=4822015 - Nov 2012 (46 comments)

Don't Call Yourself a Programmer - https://news.ycombinator.com/item?id=3170766 - Oct 2011 (267 comments)

> Engineers are hired to create business value, not to program things.

That's a false dichotomy.

Engineers create value _by_—among other things—programming computers. That's nothing to be ashamed of by trying to elevate your title to some perceived higher status by calling yourself an "engineer".

If anything, I identify more as a programmer, than to the field of engineering.

Sure, there's more to creating value in a company than just programming. A good programmer communicates well, knows when to lead and when to follow, is an insatiable learner, and enjoys understanding how things work.

> "Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.”

Anyone who thinks that doesn't understand programming, and is someone who you probably don't want to work with anyway.

I didn't read the entire article, and there is some good advice there, but I'll give a better advice to new programmers: take any opinion presented in absolutes with a chunk of salt. Follow your passions, and reach your own conclusions, rather than assuming anything a so-called expert says as the absolute truth. And, of course, be open and ready to change your opinion if presented with valid evidence.

"Strong opinions, weakly held."

> Anyone who thinks that doesn't understand programming, and is someone who you probably don't want to work with anyway.

I agree, and it disqualifies most tech companies.

>You are not defined by your chosen software stack: I recently asked via Twitter what young engineers wanted to know about careers. Many asked how to know what programming language or stack to study. It doesn’t matter. There you go.

I generally agree with this point and many others in the article but when looking for a position the tech stack of a company you're interviewing with matters a whole lot.

Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology. It probably also indicates a lot as far as what your colleagues would be like and how much you'd learn from them.

> the tech stack of a company you're interviewing with matters

Yes, this blog belongs to a (fairly large) class of "career advice the way the author wishes the world was rather than the way it actually is" blogs.

I see your point, but Facebook had large collection of code written in php(still is?), and they are far from having "lack of investment or interest in technology."

To be fair back in the early 2000’s PHP was one of the best options.

And for many purposes, still is.

To your point they also, like, wrote their own PHP interpreter. If you asked your Facebook interviewer about PHP you'd probably get an interesting answer!

compiler

twice

They are definitely the outlier and the version of php that fb uses can barely be called php when they more or less rewrote how it works under the hood.

But this isn't a dig at php, just stating chosen languages/frameworks matter a lot. I think it speaks volumes about a company's tech philosophy if they still mainly use php and jquery for web development.

What about if they use Java or C++ or Erlang for production code, rather than, say, Go or Rust?

The state of thr deployment pipeline and tests matters a whole lot more than the specific language.

> Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology.

Not necessarily. Although many would consider C an older language, it's often the right language for the right job (e.g. network packet processing).

I perceive this as:

- There is always a need for low-level programming, and there is not as much development of new languages, abstractions, frameworks, and libraries in the low-level space. Indeed, most of the time you don't want any abstraction, framework or library between you and the low level thing you want to do.

- In the high-level programming space, there is a never ending race to climb higher and higher in the software stack. As such, all frameworks tend to be obsolete faster. Either it is replaced by the new high level hotness, or it gets stuck as a middle-level somewhere, below the new hotness.

Because of that, low level things don't become outdated as fast.

It could also just be that the population of Web developers is more prone to fads and churning framework after framework passing each off as serious technological innovation when they are typically just re-arrangements based on shifting opinions. So while, in this space, perhaps, “technology is changing all the time” but really it us just feverishly dog-paddling in place.

The problem with this is that each person's definition of older/unfashionable differs. Some people think of java that way! And I would say they're wrong. Cobol on the other hand...

You don’t get it. The point of the author is that you want to be in the position where a company is hiring you, as a consulting business, to solve a particular problem they’re having. That means having very large freedom in your implementation, as long as the problem is solved.

What you’re describing is basically being an employee. When you’re an employee you typically aren’t hired to solve a problem, you’re there to fill a role. To fill the role you will need to fit whatever mold the employer wants, including tech stack.

OK, but what I quoted was specifically advice on being an employee:

>Many asked how to know what programming language or stack to study. It doesn’t matter. There you go

And I'm saying the language/stack absolutely does matter when it comes to advice for new developers.

Note the blog post is from 2011. It mattered less then.

This isn’t true. I have folders with emails each time I’ve been looking for a job since 2008 (2008,2012, 2014, 2016, 2018, 2020). I stayed at my second job from 1999-2008.

A sample of the email from 2008:

> Company in … is looking for a full time .NET developer to start as soon as possible. M leading edge technologies. This is a great opportunity for someone with strong VB.NET skills to come aboard a fabulous company.

Standard developer - minimum 2 years transactional website development experience on the Microsoft platform (don't need content/marketing web developers) Senior developer - minimum 4 years transactional website development experience on the Microsoft platform Experience with .NET 2.0/3.5 platform Experience with VB.NET and ASP.NET Experience with the AJAX framework Experience with writing SQL (Oracle experience preferred) Experience with data access through ADO.NET Must be willing to follow client's code standards and participate in code reviews Java script skills (basic

Nice to have experience

Telerik controls and other 3rd party software experience Database experience with SQL Server and DB2 databases Web farm experience (deployment and troubleshooting)

Right, it really doesn't matter—until you are interviewed by a shortsighted manager in a hurry, which is all too often.

And isn’t it a good thing that that manager helped you realize not to waste your time with that company?

I see programmers are as good at judging whole-ass companies as hiring managers are good at judging whole-ass peoples

Which is to say, they are awful at it and will act like one observation of one characteristic is more than enough data to evaluate complex machineries

You tend to work for or around your hiring manager and that managers culture rather than the whole company.

it's not about what language you're using

it's about what you accomplish.

that's in isolation of pretty much everything, even computers in general.

> Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology. It probably also indicates a lot as far as what your colleagues would be like and how much you'd learn from them.

Not everyone is looking for the same thing. Over interest in new technologies cautions me that a candidate may be more interested in hype than finding suitable technology for a problem, it's a continuum, but sometimes you see a pattern of hit and run, trying new tech and then leaving projects behind (not even them knowing what happened to them, if it turned out to be a good decision long term)... that's not attractive from a business perspective where stability is valued.

At the other end you get people who are not comfortable stepping out of the box they've made for themselves. You want a bit of both, it's good to be interested in new things and even consider them for use in production - but it must be accompanied with a healthy amount of scepticism and keeping your evangelism in check, because technology can be subjective.

Similarly, using a bleeding edge stack indicates the engineers are getting away with resume stacking and you can be pretty sure the product will be late, over budget and developers leave after a year because it turns out using any particular tech stack in and of itself doesn't mean you can create something useful.

Yeah but when you are first starting out it really doesn't matter - what matters more is keeping interested enough to keep learning and growing from wherever you start.

It will affect who you become though - 'a java shop' vs. a Ruby-on-Rails start-up, say - what people think of you, or where you're hireable.

I at least glance over all the recruiter spam I get, and not much of it takes the 'language experience doesn't matter, transferable comprehension of fundamentals does' line.

I might not be defined by Java but after programming in it since it came out in 1995, I certainly identify with it.

It's not so much that there's a best one as a bottom five. There are in any given year a certain number that you should probably just avoid.

For new greenfield projects, ok. Sure if you're at an agency cranking out brand new projects for a new customer every few months, you probably should be using stuff that's fairly up-to-date (but tried and mature, not bleeding edge).

However, if you're maintaining and developing a product that has been successfully growing its customer base for over a decade, then you don't want to be just spinning your wheels rewriting it over and over in the latest hot new fad. That wastes time and money, adds bugs, and annoys the customers.

Integrate new tech as you can, along the way to providing new value or getting new customers, but don't throw the baby out with the bathwater. It's perfectly fine to still have 'older/unfashionable' tech in the system that's still providing value and helping the sales team to close deals.

I’m sure this article is right about some stuff, but man if it doesn’t make me sad to read.

Software can be so exciting and fun, and this “careerist” perspective really sucks the joy out of it.

If you’re looking for something that is kind of the opposite of this article: https://ferd.ca/the-little-printf.html.

It's accurate, and completely depressing as you note.

That was a fun read.

On the flip side, the reason so many musicians get exploited by the recording industry is because music is supposed to be fun. So their agents arrange for fun and keep the money for themselves.

I think it's more that there's a structure of abusive intermediation (that being the recording industry as a whole, not just the agents) that has successfully inserted itself between creator and audience such that it is able to extract it's troll toll, and artists are unable to route around it because the industry act as gatekeepers and without them you won't be able to reach a large audience.

> Software can be so exciting and fun, and this “careerist” perspective really sucks the joy out of it.

This reminds me of people arguing that scientists miss life’s beauty because they attempt to analysis it. You can enjoy the wonders of programming while still being mindful of your career progression, one does not preclude the other.

> (P.S. You probably don’t want to be first employee for a startup. Be the last co-founder instead.)

Not only for the better equity deal. In an early startup of a handful of people, there's already a power hierarchy and people are still figuring things out.

If a cofounder wants to pull a key decision out of their posterior which they know everyone else would disagree with, or wants a big career-building or fun startup thing to themselves, they still need informed consent of the other cofounders.

This is a time when it might be very convenient for a cofounder to modify their idea of mostly-egalitarian startup team dynamics, to think of employees as, well, only employees. You being cofounder here helps keep everyone honest with themselves and the rest of the company, which can be good for everyone.

I won't dispute that calling yourself a programmer is bad for your career.

But now that nobody is listening, let me tell you my little dirty secret: I can't think of any other occupation label that defines me better. And, it might be silly, but calling myself a programmer makes me really happy.

A few days ago, someone submitted pg's article advising keep your identity small [0], or at least the smallest you can. Being a programmer is part of my minimum set.

But of course, saying the truth about it, like saying the truth about so many things [1], can be very bad for you.

[0] http://paulgraham.com/identity.html

[1] http://paulgraham.com/say.html

This sounds like Dale Carnegie stuff. Dale Carnegie was a salesman; I wasn't, I was a technician (a programmer, if you like). I had six months of serious sales training, but sales isn't the trade I was made for, although I enjoyed working with salesmen.

It's true that hirers expect you to sell yourself, beyond just showing that you're qualified for the job. But I don't mind saying I'm a programmer by trade, and good enough for the job you're offering. It's up to my manager whether I add $500,000 to the bottom line; in general, engineers/programmers/technicians don't get to choose what they work on.

<< (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)

Oh boy. Ask for forgiveness later may work at a smaller joint, but willfully and knowingly bypassing existing policies can land you in a heap of trouble at a bigger corporate. The boss may be happy, because he is an idiot with no concern other than getting a bonus all the while security of the product ( and possibly the company itself ) is undermined by one coder.

And I am saying all this as I am trying to convince my boss that Python may be better suited for some tasks than Excel ( long story, some stuff is kinda locked, but not completely ).

Bottom line is.. some rules exist for a reason. Break those only if you understand why they can be broken ( and you are comfortable with explaining stuff should it fail in your lap ).

Edit: Honestly, that one piece of advice makes me really start to appreciate why some things are the way they are.

> Ask for forgiveness later may work at a smaller joint, but willfully and knowingly bypassing existing policies can land you in a heap of trouble at a bigger corporate.

Interesting. I've found that the bigger the company the more I need to do that. In a small company I can actually discuss things with people and a motivated decision rolls out. In big companies I ran into one of two problems.

1. Many people dare to say no, but few dare say yes. I have seen discussions about spending half a day engineering time kicked up three management layers because it wasn't a pre-approved task. It was obvious to everyone that it needed to be done too.

2. People just not deciding. If you don't keep chasing a decision, nothing will happen.

The political cost of a bad decision grows the higher up it goes. Make a bad decision as a grunt and you get chewed out a bit. As long as you were genuinely trying to help the company, it's nothing you can't get out of with a bit of charm and a willingness to learn. Make a bad decision a bit higher up and people start sharpening their knives. Sometimes it's better to just decide for your manager and give them plausible deniability.

> Sometimes it's better to just decide for your manager and give them plausible deniability.

Exactly! I don't mind saying sorry. And as long as you get the results, it turns out that most people that matter don't really care about all the bogus policies you ignored.

so when will we declare this advice outdated? Or extremely limited.

The first thing that is outdated, the advice is basically don't be a programmer be an expert in something the company needs. The thing is in the modern world the company often needs programmers more than it needs the other expertise, hence the big salaries we earn getting hired to solve problems.

>There are companies which create software which actually gets used by customers, which describes almost everything that you probably think of when you think of software. It is unlikely that you will work at one unless you work towards making this happen.

I mean, I've never done anything to try to be writing customer facing software but, aside from some international standardization work, that is all I have ever really worked on.

I think between 2011 and now that stuff changed, and maybe it was already very well on the way to changing in 2011 but the person who wrote this wasn't aware it was changing.

> The first thing that is outdated, the advice is basically don't be a programmer be an expert in something the company needs. The thing is in the modern world the company often needs programmers more than it needs the other expertise, hence the big salaries we earn getting hired to solve problems

I was a boring old “enterprise programmer” from 1996-2016. I belatedly started moving into more “architect” type roles where I was brought in to lead by example and while I was still hands on, I was hired to solve more strategic issues and lead initiatives.

Fast forward to today and now I’m a “cloud architect” working in the consulting department at $BigTech.

Right now I’m working on a “DevOps” project that required a few relatively trivial Python scripts as part of the design. Most of my time has been spent “consulting”.

ChatGPT was able to spit out every Python script that I needed correctly and all I had to do was tell it - this is the input I want and this is the output I need.

It got me 100% there with code that didn’t require the AWS SDK (boto3). It does have some understanding of the boto library. But it isn’t perfect.

Yes I know how to program. But I only started making real money when I could talk to “the business” and know what to program.

This more or less describes my career trajectory up to the point of belated moving into architecture roles. It’s encouraging to hear that such a winding career path can eventually make its way $BigTech. Cheers

Some good advice here, some things are rather dramatic. I do like the encouragement to highlight the value you bring to the company. But "don't call yourself a programmer" is a bit dramatic. Highlighting your ability to program is pretty important.

The way I typically try to highlight my development contributions - if it isn't direct user-facing feature development - is to portray my software as internal "mini salesforce" for niche high value tasks for other employees. For instance at my first internship I automated manual tasks like thumbnail creation, searching and calculating market share of our company, and other tasks. It's fine to call yourself a programmer, just be sure to emphasize "I program X and Y that are crucial for teams A and B".

> It does not matter to the company that the reporting form is the world’s simplest CRUD app, it only matters that it either saves the company costs or generates additional revenue.

This is my advice for young programmers too, but with a different takeaway. Most software will be mind crushingly boring CRUD.

If you do programming for the love of the craft then try to find something that isn’t that. Find something that solves interesting problems in an interesting way. It might pay less and you may not be able to jump jobs every 4 years - but you won’t be bored to death writing code which is basically 90% fluff and plumbing and deployment.

Finding jobs with actual programming joy at the core is like finding gold.

It’s all about positioning one’s career where one has max leverage which lead to relative higher career earnings; hopefully converting some of this to cash producing assets.

It’s similar to other advice I have heard such as one’s communication and general peoples skills tends to lead to favourable career success after a certain threshold.

A great article on why one should not depend on technical skills alone is https://leveragethoughts.substack.com/p/dont-hinge-your-care...

It itches me when programmers call themselves engineers. Actual engineers have licensing requirements, they have responsibility, they even can go to jail if a bridge they designed falls down. Have you heard of any of Tesla AI "engineers" going to jail after people died in self-driving crashes?

It itches me when people get pedantic about what to call things and take it upon themselves to define what an "actual" engineer is.

From Wikipedia: Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build and test machines, complex systems, structures, gadgets and materials to fulfill functional objectives and requirements while considering the limitations imposed by practicality, regulation, safety and cost.

What part of this does not apply to software engineers? They can't go to jail therefore they're not engineers? What bullshit gatekeeping.

It depends on the country/state/laws/industry/field etc. In the UK, everyone is an engineer. The guy who checks your gas meter readings is a "gas engineer". In the US, I think it's "professional engineer" that is the protected term (depends on the state I'm guessing).

I used to work in the semiconductor industry, no one gave a shit about licensing, but I would still call it "real engineering".

Going to jail isn't a prerequisite for something being an engineering discipline. I think software can be "engineering", depending on the process used to develop it. But the "move fast and break stuff" philosophy is pretty anti-engineering, in my opinion.

This becomes almost a philosophical discussion about what engineering entails and the definition of words. Personally, I don't care that much if people call themselves engineers or consider what they are doing engineering. Even if all they do is copy-paste code from SO to glue together npm libraries.

It says "Bachelor of Engineering" on my diploma though.

Also not all engineers have licensing requirements and responsibility - chip designers are one example. Engineers in every sense of the word, but no obvious licensing requirements nor responsibility on the scale e.g. civil engineers have. Generally much closer to what we do as software engineers.

“You’re not defined by your chosen software stack”…

Boy this article is old isn’t it.

Timeless truths have a way of living on forever.

I don't understand why so many people seem to disagree with this point.

If you're a specialist that's one thing, but a normal software stack should be generalizable?

I got hired at all of my jobs so far without having major prior experience with the languages they use, and definitely not the frameworks.

Myself and others would consider your experience unique/not the norm. If you don’t mind me asking, what was the mechanism used to obtain those jobs? Was it primarily via networking or word of mouth, did you have some type of in? Or were your jobs with smaller employers or startups perhaps? Because in “The Enterprise” you’ll be disqualified straight away if you don’t have a certain amount of experience in a certain framework.

If I had a nickel for every time I’ve tried to explain that every new technology I’ve learned I’ve picked up on the job and specific framework experience is largely irrelevant, I’d be a rich man.

For example, I’ve been a software engineer for 27 years using tech stacks primarily within the Java ecosystem but encompassing many different frameworks, languages, databases etc. However, getting a job in a similar or even identical business domains but on the .NET tech stack would be next to impossible.

I might be atypical, for sure. I've moved through Java, Go, Python, c++ and recently to Scala now, with no contacts at any of the companies I've applied to, but hopefully good references in each case. I've only been a dev for 7-ish years and had 3 separate jobs in that time. Youth might have given me some leniency in the first moves, but maybe less so in the latest one.

Im from a small country, so it might just be that the developers have a stronger hand at the negotiation table than elsewhere, since there're fewer competent devs as a result.

In any case, as a programmer I feel like I would always hire someone that demonstrates good programming skills in the "wrong language" over someone who's mediocre in the "right language", so it's sad to hear that's not the case many places. And that might be a lesson I should keep in the back of my mind as well.

When I was reading Dijkstra's wikipedia page and read that he called himself a programmer I suddenly wanted to start calling myself one.

A d100 does have a 100 side, just like you can roll a nat 20 on a d20. True about rand(100), though. So be the die-rolling kind of geek:)

> Engineers in particular are usually very highly paid Cost Centers, which sets MBA’s optimization antennae to twitching

disagree completely with this.

I view scientists, engineers, programmers, and system administrators as a part of the profit center because they are intrinsically tied to value creation and value amplification.

Agree with your disagreement! Whether classified as cost center or profit center largely depends on the type of company or organization. For the first half of my career, I would agree with OP: that engineering was viewed as a cost center. However, after transitioning to a software company, me and my teammates were generating revenue.

It depends on the company.

For software companies, sure! Unless you're in DevOps or DevTools then you're a cost center again.

For an insurance company or restaurant, not as much. It depends on where the flow of money is.

Things are changing though, so this is less true over time as software continues to eat the world.

Yeah this is an important point. Amazon viewed themselves as a software company almost from the beginning. Now a considerable portion of their business is from AWS because of that mind set.

> I view scientists, engineers, programmers, and system administrators as a part of the profit center because they are intrinsically tied to value creation and value amplification.

Its a perfectly sensible view. unfortunately not one shared by your typical bean counter. MBAs routinely buy out companies and gut the value creation parts to increase valuation for short term gain before pawing off the hollowed out shell to the next owner. its sick but widespread.

The whole idea of a “cost centre” is nonsense anyway.

A useful word for describing the optimization of something that adds shareholder value is appreciated by those who consider it.

> I view...

well, you're not a MBA or a decision maker so your input here is mute. People are the means of production for a technology company and people cost money. This isn't complicated. And make no mistake, great measures are taken to minimize costs.

Whether you label something a profit center or cost center is irrelevant to the authors point. The significance of the conclusion remains true regardless of the label used.

It depends if it is a software company or not.

I think this article is an insult to MBA's intelligence. Today, they know perfectly well the value of code monkeys aka programmers.

Do they? Plenty of places still put IT down as a "cost center" first and foremost, using that as a basis tobproactively run their staff barely above the level required for maintenance alone.

Conversely, they also tend to believe their value calculations are better than those of dev teams, going as far as to ignore proposals. You think MBAs are able to consistently guess better than someone actively doing the work?

> I was once reduced to tears because a minor academic snafu threatened my ability to get a Bachelor of Science with a major in Computer Science, which my advisor told me was more prestigious than a Bachelor of Science in Computer Science.

I'd really like to know more about this distinction

The options grant appraisal for startup employees seems very optimistic - 70% it's worth nothing. 25% payout is equivalent to all the backpay you would have gotten if you had worked at a big tech co. instead. 4% life changing money but not the richest person you know. 1% you are the richest person you know.

Was this the generally the way people thought about it back then? I remember seeing fairly pessimistic valuations around 2013 though, and I see it more like 10-15% chance of big tech salary equivalent, and 1-2% for life changing.

I deliberately call myself anything but engineer, pretentious

Don't be ashamed to call yourself a programmer. Alex Stepanov, who created hundreds of billions in value by creating the C++ stl calls himself a programmer.

I call myself a programmer, because it's one word rather than a paragraph, and it's the bulk of what I do.

Me too, specially in social settings. It nicely stops the conversation about work.

Trying to decide if you're being ironic.

I find that even saying "I'm a programmer" in social settings triggers my counterparty to frantically start scanning the room for anybody else to talk to.

In social situations when that comes up I usually say something like "I work for <employer>" and then immediately try to change the subject.

> Trying to decide if you're being ironic.

Not ironic at all. I actually work in machine learning but saying anything close to "AI" is a fatal error.

I got the exact opposite advice decades ago if you want to remain technical. If you start becoming the company expert on their business processes as a programmer, time to move to a new company.

That served me very well and I remained a programmer for my whole career.

I think this is very good advice for many programmers. I think a lot of programmers become stagnant in sone company because if the phenomena you describe.

this is so dumb. software engineers / developers etc program computers. so they are programmers. what has this world come to

Blah, I’m a programmer and being one has never once been a career hindrance. No one is trying to put me out of a job because of salesforce or whatever. I’m trying to program myself out of a job but haven’t been able to for 20-some years. I doubt I ever could.

If you need to hint towards „salesforce“ in your pitch then something is fishy.

Btw. whatever happened to understatement? Is that not cool anymore?

Oh and Don’t ever call yourself a systems architect unless you want to be ghosted by the programming people.

Past comments: https://news.ycombinator.com/item?id=3170766

Don't call yourself an Engineer unless you are licensed to do so. Most states have a professional licensing board to oversee the practice of Engineering. Here's the link to the one in my home state of Indiana.[1]

I've been a programmer, system administrator and a machinist. I've never called myself an engineer, and wouldn't want the criminal liability for doing so.

I wouldn't call myself a "computer doctor" either for similar reasons.

[1] https://www.in.gov/pla/professions/engineering-home/engineer...

The criminal liability is in lying specifically about having the PE license, for work that requires it. Nobody is going to prison for calling themselves an "engineer" on their resume when they apply for a job that itself is called "engineer" by the recruiter.

Given that companies like Google have positions for “software engineers” or “engineering departments” and simultaneously hire armies of attorneys, I would have thought this would have come up. *

* Not legal advice or proposed by a practicing attorney of any U.S. state.

Why would you give that advice when the job titles are all "xyz engineer"?

I would simply not use the title anywhere. If I got an interview or offer, I would point out the problem with the job title at that time.

I think people would find that really weird. Potentially "bad culture fit" weird.

Interviews are two way; if it really annoys somebody to be called an engineer when they aren’t licensed or doing what they think of as engineering work, then… I guess it is a legitimate bad culture fit, right? If that’s the hill somebody wants to die on, might as well get it out of the way!

IMO — I’d prefer not to be called engineer but we live in a capitalist world — if someone is willing to pay enough they can call me whatever they want.

People are free to attempt to break from society and never use money because of some crazy SovCit conspiracy too. But this was proposed as advice and presented as kind of some correct thing to do so it is quite available for criticism. It is a very strange, mercurial position that no one should really follow if they want to achieve goals discussed in the OP article, such as being financially successful in one’s career.

This is absolute madness. Just accept the game for what it is. If they wanna call software developers "software engineers", what do you have to gain by swimming uphill?

The irony is that it also applies to electrical and mechanical engineers that very often do not hold or intend to obtain a P.E.

You would point that out to a serious, billion dollar company that is interviewing your for a software engineer position? Really? Maybe you don’t realize how bad that sounds. That is actually pretty silly; it would be like you claiming to have secret knowledge or some kind of legal training superiority to a companies that employs or otherwise retains the services of an army of top tier attorneys.

You are free to personally think that software developers should not be called engineers, but you are simply factually incorrect if you are telling an employer they are in legal trouble for calling their unlicensed employees software engineers. There is no legal issue, and the industry as a whole has clearly decided it is not a problem with using the job title.

Software “Engineers” have this magic spell called a EULA.

You are very much legally in the clear to call yourself an engineer, even if your actual title is "Solutions Engineer" (i.e., sales).

You cannot however represent yourself as a licensed professional (engineering or otherwise) without actually having that license. That's what's illegal.

That could be the case wherever you live, but this isn't true in general. The word "engineer" is protected title in some countries (without requiring additional qualification such as the word "professional" or "licensed").

Your username suggests you’re from the Netherlands. AFAIK ‘engineer’ is not a protected title here (as opposed to ‘ingenieur’, which is protected).

I think I remember reading it's not even consistent across the US, that some states have the same protections on the title.

This is very good advice, if you want to work in Germany. The general requirement to call oneself an engineer ("Ingenieur") is that a person has successfully completed a technical or scientific course of study at a German university or university of applied science with the duration of at least three years (full-time). Each German state has its own Engineer Law ("Ingenieurgesetz", IngG) for the details, which also include the regulations regarding the recognition of foreign qualifications and fines for unauthorized use of the title (for example, up to 25,000 Euro in Baden-Württemberg).

Does this mean a physics degree qualifies?

For example the Engineer Law of Baden-Württemberg states in § 1.1:

  (1) The professional title "engineer" may be held by anyone who

  1. has successfully completed a course of study in a technical or natural science subject with a standard period of study of at least six semesters, corresponding to at least 180 ECTS credits, at a German state or state-recognised higher education institution, whereby this course of study must be predominantly in the fields of mathematics, information technology, natural sciences and technology, ... [1]

My own interpretation is that not all of these four aspects need to be included equally in a course of study. If the question is of practical importance to you, you should contact the Chamber of Engineers of the respective (federal) state for an authoritative answer.

[1] Original:

  (1) Die Berufsbezeichnung »Ingenieurin« oder »Ingenieur« darf führen, wer

  1. ein Studium in einer technischen oder naturwissenschaftlichen Fachrichtung mit einer Regelstudienzeit von mindestens sechs Semestern, was mindestens 180 ECTS-Punkten entspricht, an einer deutschen staatlichen oder staatlich anerkannten Hochschule mit Erfolg abgeschlossen hat, wobei dieses Studium überwiegend von den Bereichen Mathematik, Informatik, Naturwissenschaften und Technik geprägt sein muss, ...

Source: https://www.landesrecht-bw.de/jportal/portal/t/3ba/page/bsba... (in German)

"Software Engineer" (without German translation) is used as an official job title by many German companies and the German linkedin is also full of people describing themselves as Software Engineers. This is the first time I hear such an objection.

From the German Wikipedia article on "Softwareentwickler":

My translation:

  The job title _software developer_ is not a protected job title in Germany and Austria.

  According to German law, the job title _software engineer_ may only be used by those who have successfully completed a technical degree. In Austria, the title of engineer can also be acquired through training at an HTL [Höhere Technische Lehranstalt, aprox.: Higher Technical College].

Original:

  Die Berufsbezeichnung _Softwareentwickler_ ist in Deutschland und Österreich keine geschützte Berufsbezeichnung.

  Die Berufsbezeichnung _Softwareingenieur_ darf nach deutschem Recht nur führen, wer ein technisches Studium mit Erfolg abgeschlossen hat. In Österreich kann der Ingenieurstitel auch durch die Ausbildung an einer HTL erworben werden.

Source: https://de.wikipedia.org/wiki/Softwareentwickler#Berufsbezei... (in German)

This all might very well be, but it does not reflect reality. Everybody calls himself Software Engineer, nobody calls himself Softwareingenieur.

As if Google Deutschland would not hire you as a Software Engineer (or SRE, ..) if you are missing a B.Sc. (or did it in a non-technical field) but everything else is perfect.

This is not about hiring, it is about what you are allowed to call yourself, i.e. what you are allowed to write into your CV on your buisness card, on your Web site or use for self advertisment. Don't expect to get away with calling yourself an "Engineer" if you are not an "Ingenieur". Judges do not like to be fooled.

Job adverisments in German almost exclusively use the term "Software-Entwickler" ("software developer"), indicating that an IT degree is not necessarily required for the job.

> This is not about hiring, it is about what you are allowed to call yourself, i.e. what you are allowed to write into your CV on your buisness card, on your Web site or use for self advertisment.

If my job title is Software Engineer, then this is of course what it written on my business card that my employer prints for me.

> Job adverisments in German almost exclusively use the term "Software-Entwickler"

This is just not true.

>> This is not about hiring, it is about what you are allowed to call yourself, i.e. what you are allowed to write into your CV on your buisness card, on your Web site or use for self advertisment.

> If my job title is Software Engineer, then this is of course what it written on my business card that my employer prints for me.

If you are not entitled to do use the title, then it is illegal nevertheless. After all, the law applies regardless of whether it is followed.

>> Job adverisments in German almost exclusively use the term "Software-Entwickler"

> This is just not true.

A search for "Softwareingenieur" or "Software-Ingenieur" on gulp.de, the leading IT freelancer platform in Germany currently gives zero results. If you search for "Software engineer" you get results mixed with "Softwareentwickler". So I went through these results which gave me aprox. 10 cases where they were looking explicitely for an "engineer" ("aprox." because I excluted those where "engineer" was one option among others or were they were mentioning the field "engineering" -- but even those were only a few). In contrast to that, when I searched for "Entwickler" or "developer", I got 275 results.[1] So the proportion of "engineer" is aprox. 3.6 % to that of "developer"/"Entwickler". I think it is okay to call that "almost exclusively".

[1] Some of it are a bit general, so you may not want to count everything. A quick random sample seems to indicate that the number is low nevertheless; so I went with 275, because the end result is unlikely to be significantly different.

This is utter nonsense. Words always have more than one definition.

Every term that has a legal (or precise subject-specific) definition also has a common-use definition. Engineer is no different, and the law knows and understands this.

This is why the term licensed engineer is a thing.

I agree in sentiment. You're fighting a losing battle though. People like inflated, grandiose-sounding titles that make it sound like what they do requires a mysterious rare skill.

We are builders, with some amount of analytical ability and creativity. We aren't much different from pipefitters, blacksmiths, or furniture builders, and we aren't any smarter than those people.

Sour grapes from lower paying engineering disciplines that have been hijacked by certification organizations. I’m a software engineer. I earn triple what you earn as a civil engineer, and I don’t have to pay a certification body for the title. I can also work in any state that I want, and I can move without second thought or recertification. Go cry about it.

Beyond certification, licensed engineers are able to be held personally liable for negligence. Perhaps in a jurisdiction that only allows licensed engineers to call themselves engineers, you sound like someone who doesn't want the burden of the title, either.

Crouch down and lick the hands of the mafia organization that rules over you. May your chains sit lightly upon you. Enjoy your $90k terminal-career salary, geographic lock-in, and annual dues! At least you’re grateful for the right to call yourself the title that you already earned as an undergraduate! May this affliction never effect the software ENGINEERING industry!

I don't know how you have so much contempt over the people who ensure that everything from roads to physical infrastructure in the modern world function and enjoy spitting on them so much like this.

I enjoy spitting on people that try to control my speech and my title. Misery loves company, and I will not join you in your misery.

I appreciate the bridges and roads, but I will not be told what title I can have just because YOUR industry (and tongue) has been captured.

This seems pretty hyperbolic. Are electrical engineeers not engineers since the majority of them don’t get a P.E. Are you seriously that worried about criminal prosecution? That seems like a different kind of problem, if true.

It depends on where they practice. In some countries, they should absolutely be worried about misrepresenting themselves as licensed engineers.

For example, in Canada, the title "engineer" is reserved for licensed/professional engineers, so it would be misleading to use the title "electrical engineer" if they're not actually licensed.

Since we’re generally sitting on top of a giant pile of semi-understood abstraction that doesn’t have a real mathematical model and is often defined by matching legacy behavior (aka precedent), “Software Lawyer” could be a better name.

Naw, we should be honest about what we actually do, mostly so we can stop pretending our industry is good at what we do.

We are "Framework and API plumbers" by and large, taking existing packages and just hooking them into each other.

Plumbing generally works despite being constrained by real world non-idealities and things like wear-and-tear.

We belong with the lawyers, who are working in an entirely human constructed framework but have somehow fucked it up so bad that it has loopholes and undefined/unexpected behavior.

Is that not what we're doing with distributed systems? A lot of the theory & practice of our field is how to elegantly cope with servers dying, data being corrupted, load limits of single machines, etc. We have a lot of constraints.

And there's no possible way not to have some leaky abstractions with this in front of us.

I will concede that in some instances we reach a level of thoroughness that could be considered more like plumbing.

But it is less funny if we go with code-plumber, the goal here is to justify trying to steal the protected job title.

There is a large world of programmers outside of the Web world.

I'm not an engineer or a lawyer. ;-)

Nobody's skirting the law. In most US states, there is a so called "industrial exemption," which allows you to do engineering without a license if you work for certain kinds of employers. I work for such a company, though I don't have an engineering title. But when we do offer a product for sale to the public, it goes to a third party for approval, and the people at that company who conduct the design review all have engineering licenses. The thing that will get you in trouble is offering engineering services directly to the public.

Now in my state, there are only licenses for a small handful of engineering disciplines: Electrical, mechanical, power, etc. I don't know if it means that the rest of us can't call ourselves engineers at all, or if we're just unregulated. I've never tested those waters.

From what I've observed, people with engineering job titles rarely do any hard quantitative engineering. Most of the work consists of organizing and arranging things, fitting things together, troubleshooting, etc.

Here in Japan you can hear someone calling themselves a software engineer, fresh out of a bootcamp. The original meaning of engineering has gotten lost over the time, diluted by a sense of self-importance.

Imagine a world in which we let the bootcamp grads build our bridges and medical devices (Therac anyone?).

I don’t mean to be a gatekeeper. Keeping someone from practicing medicine if they won’t get a degree is not gatekeeping by anyone’s definition.

„Trust me, I am a software engineer“ just doesn’t have the same ring as „trust me, I’m a doctor“

The risk of criminal liability in many countries is most likely low, as long as you keep the anglicized term and not call yourself Ingenieur (engineer) in Germany or for example 工学者 (こうがくしゃ, kougakusha) in Japan, both of which imply that you have a degree in engineering.

To make things more confusing, the information technology qualification I possess in Japan called 基本情報技術者試験, loosely translated as fundamental information technician, is often translated using engineer instead of technician.

Some countries do over software or information engineering degrees, with a professional body regulating them, but I find that to be the exception.

The battle is already lost.

> The original meaning of engineering has gotten lost over the time, diluted by a sense of self-importance.

The original meaning is "someone who builds machines, particularly siege engines, or who constructs defenses against those machines". Is that really what you're complaining about?

Perhaps you're referring to the meaning "a guy who shovels coal into a train engine"?

When people talk about licensing programmers, I always say: "Better watch what you ask for." Licensed means regulated.

> Keeping someone from practicing medicine if they won’t get a degree is not gatekeeping by anyone’s definition.

It's gatekeeping that we all pretty much agree is a good thing, but it's still gatekeeping.

I think it largely depends upon the state, but I agree in sentiment.

I think what I'd rather like to see is an industry standard professional engineering board for computer science. I think the field could actually do with some minimal barrier to entry even if that sounds like gatekeeping.

Not having a professional software engineering license wouldn't prohibit you from taking jobs or practicing software development, but it would help to guarantee a certain level of fundamental grounding in computer science that certain employers might desire in their prospective employees.

>"Don't Call Yourself a Programmer"

I never have. I've always advertised myself as a guy who designs and develop products. Not always pure software for that matter.

I plan to use this line of thinking to my advantage when I am able to employ people. I will deliberately call myself a programmer, avoid formal titles and just call everyone programmers, emphasize that the job is about solving hard programming problems and so on. That will attract creative people for whom the difficulty of the work is a perk and not a cost.

I am not a programmer. I am .. Agent Cody Banks! (⌐■_■)

Reply on news.ycombinator.com