I've been brainwashed for many years by my brother, who is a Phd civil engineer, that professions that hijack the term engineer are kidding themselves.

I know it sounds cool, and my current title is 'Senior Software Engineer', but it is all a scam.

  https://en.wikipedia.org/wiki/Rent-seeking

Which isn't to say we aren't worth it; I'd like to think we are. Just that we often delude ourselves into thinking that our salary differential is linearly correlated with the economic "value" we generate. It isn't.

Or rather: the "value" of an engineer is a lot like the value of an apartment in a high-rent neighborhood: the price holds in the market because, well, you have to have it, and at (almost) any cost in order to do all the other stuff you need to do, like get around the city and be close to your job.

You also have to have access to food and safe drinking water -- even much more than you need a convenient or semi-stylish apartment. The priority for these isn't just a bit higher: it's categorically higher. Yet their base cost (i.e. the cost to obtain them at nominally satisfactory level) is an order of magnitude less than the cost of your rent.

The distinguishing factor between the two classes of goods is, of course, scarcity. That is why your rent is damn high.[1] And that's why an average software developer can earn twice as much as a decent chemical engineer, and an ungodly multiple of what a great public school teacher makes.

[1] Along with the fact that high-demand apartments -- like high-demand engineers -- are also, arguably, Veblen goods in some markets:

   https://en.wikipedia.org/wiki/Veblen_good

[1] http://work.chron.com/salary-petrochemical-engineer-4334.htm...

Comparing with my friends who are still doing ChE jobs, If I was still in petrochemical, I most probably be getting paid little less than what I am being paid now, but working much more harder, longer and more stressed.

Ok clearly I am out of touch then. But seriously, how many SE really gets paid 250k+, even at Google? Quants is in my mind the same as the petrochemical industry tough, rediculous salaries so that one I can believe.

So, yes, I am an Engineer.

You can't even design an embedded electronics device for a 3rd party (for a company you work for, is ok - industrial exemption) or write software for the same without a PE.

[1] http://sce.uhcl.edu/helm/SWEBOK_IEEE/papers/10%20reprint%205...

The whole frame of mind in which I do EE is incredibly different from the one in which I do programming, to the extent that, for much of my early career, there was simply no way I could do both of them efficiently during the same day. The time of context switching was, literally, a good night's sleep. There are marked differences; the ones that spring up immediately are:

1. I spend a lot of time doing actual computation, optimizing my design on paper and attempting to predict interactions that occur due to reality not being quite like its ideal model. Some of the younger engineers frown upon this (mostly because they suck at math and think theory is for bookworms), but it's very productive once you manage to do it right.

2. Even when specifications are complete and respected to the letter, there are still differences between what you specify and what gets built. There are technological variations you must account for.

3. Better yet, you always need to bear in mind the limitations of the manufacturing process for what you design. When I think about how I'll write something, my own ability to code is literally the only limit I have to deal with. There are, of course, hard limits due to the constraints of the platform you work on (e.g. there is some hard limit to how much code you can fit in 16K of flash), but these are of a very different nature compare to manufacturing constraints. Designs must account for the limits of your technological process (e.g. you may not be able to mount some types of components on a PCB), and they must also ensure manufacturing is feasible and scalable (something called DFM -- Design For Manufacturing -- which I have screwed up a couple of times, due to my inexperience).

Overall, there's a huge gap between how much intuition and craftmanship I put in each activity.

I'm not saying this disqualifies programming as an engineering discipline; such differences may also exist between other engineering disciplines I have no idea about.

I, for one, tend to frown upon it being called "software engineering" though, mostly in virtue of these differences. I don't consider the term "software development" demeaning -- in fact, I prefer it, and I always present myself as a programmer and my job title as "software developer", even though I'm legally allowed to call myself an engineer.

But there are a couple of things that make me personally think software engineering is a misnomer.

Firstly, traditional engineering disciplines are generally pretty black and white. It is applied maths and science. If you build a bridge, you can use physics and maths to pretty much prove that it will handle a particular weight/load and so forth. Software development is rarely like that, and even if you are writing software for an engineer and therefore you could argue that you can prove the calculations the system is generating, it is really the problem domain that is engineering but the way the software is put together is not so easy to prove.

Secondly, I think the term actually does us a disservice. Software development requires intuition, craftsmanship, pragmatism, determination, adaptability, artistry. It also often requires understanding human nature, empathy for users, being able to learn and understand endless problem domains, an eye for the aesthetic. All of these things aren't generally required for traditional engineering disciplines.

I would say that the essence of engineering is a devotion to verifying that the design works like you think it works. Software development often lacks this devotion, but when it is there it is entirely proper to call it software engineering.

#have argued, actually

That's why i call it software development, and i m a software developer.

One of my internships was at a company that did avionics software. Avionics is about as different from Web 2.0 startups as you can possibly get and stay in the same industry. There are very rigorous traceability metrics that pretty much dictate exactly what can go in the software. Every line of code has to be traced back to a particular paragraph in the design doc, which has to be traced back to a particular numbered requirement. Oftentimes garbage collection or even heap allocation is banned to avoid unbounded pauses in execution time. So the behavior of the code is fully specified under all conditions, and often formally verified. This was the one place I've ever worked where I'd hear "So we should write it in Ada then?"

I've also worked in the financial industry. Little known fact about the financial industry: it's not one industry but many. The code that you'd use to build a quant trading model is very different from the code you'd use to build a retail banking portal. The former actually tends to look a lot like academic research code (i.e. a software engineer would consider it shitty, but it has impressive math and gets the job done).

I work in consumer web now, but at Google. We actually do care about latency, and CPU load, and memory consumption, and developer productivity. And so it actually ends up being a lot like real engineering, where you perform experiments to measure the performance of the building blocks you're using, carefully consider goals and trade-offs, make estimates and back-of-the-envelope feasibility studies before implementing, and then rigorously test that solution.

This is in complete contrast to when I had my own casual gaming startup, where neither performance nor reliability mattered all that much, the only thing that did was the user interface.

See IEEE for instance...

Also the engineer term is a protected designation in many countries, just as doctor and laywer is...

Others are less rigorous, but can still are the practice of engineering. Software Development is one of those.

The title implies a certain amount of rigour and due diligence being applied at all stages of a design, as well as compliance with all relevant standards and regulations. This is audited by certification bodies and explicitly stated by your signature on any document or code you sign off on.

Personally I think this is somewhere that software development could head in the future, but there seems to be too much disagreement on coding best practices to standardise them, and anyway I doubt most people would be willing to pay the cost associated with this, for the majority of software.

For example I am getting a "Software Engineering" degree. It has all the same math and science classes as other engineering majors.

If I ever want to use my title as engineer I will be held to the same standards as other engineers.

https://en.wikipedia.org/wiki/Software_engineering_professio...

In reality, I was barely a junior dev, and being in charge of a site that's getting millions of views was absolutely terrifying. In some ways, it was one of the best training exercises I could have. It forced me to learn things, and to learn them well. It was also total bullshit. My pay wasn't that great, and although I was working in a startup that was slowly becoming technical, had absolute control over technical decisions, and was able to turn a company that struggled with FTPing to a server into one with automated builds, regular code reviews using a new source control system (Git), and much more, it still highlighted more than anything that I really didn't have the slightest clue what I was doing.

It really couldn't have gone better for me. The company was acquired, and I landed a job at a great agency, and was able to work on enough projects to actually know what I was doing, and to see what good code looks like. I'm a mid-level developer now, with much better pay, but instead of looking back over old code and laughing, I tend to look back over the time where I led the technical side of a startup and laugh.

Can you believe that when I started, barely anyone used source control? That's what jumped out at me about your story, oddly enough. When I started the Web hadn't been invented, and the only version control packages were CVS and commercial options. CVS sucks, in case you're wondering. So did most of the commercial options.

In my own case I'd been programming and writing games for fun since I was 14, so by the time I took my first job at 22, I'd already been coding pretty regularly for 8 years. Some of that was actually for-pay, though only a few months worth. So between the experience I did have and my oversized ego, I pretty much expected the "Senior" label.

He then became the sole member of the business :-)

Well normally they only hired people with 6+ years of solid web development experience as senior engineers (just like no one today would think of hiring a senior Node.js developer with less than 5 years under the belt). But they decided to give the article poster a break for his people skills and Team Player potential.

The idea that Time Warner already had a sophisticated Web division smells like BS to me. I would accept 1997 or 1998, but not 1995.

https://en.wikipedia.org/wiki/Pathfinder_(web_site)

It was not sophisticated by today's standards, but it was one of the first real magazine sites on the web. Here are some screenshots.

http://www.disobey.com/ghostsites/pathfindermuseum/index.sht...

> The idea that Time Warner already had a sophisticated Web division smells like BS to me

the title 'senior' doesn't imply the division was sophisticated. If something smells like BS, doesn't mean it can't exist. There is a lot of BS around.

attributed to Napoleon Bonaparte