I think the distinction is in 'one who implements' vs 'one that designs'.

There are mountains of people who can take a spec and implement it in code... but they just are code monkeys who take literal definitions and implement them in a known language. With them, you get little creativity, little ingenuity, and will drive directly into a wall if that's what the spec says to do and call it 'complete'.

Where as a true Developer/Scientist works beyond the 'writing the code' and actually is capable/responsible for working on the algorithms or strategies on how to tackle the problem. They also scheme the new ways to solve the problems. They don't just 'implement', they 'create' and then just map those ideas into code. In my experience they are far more likely to come up with elegant approaches in the software because they aren't just using lego blocks, but instead understand and take into consideration what the compliers or hardware constraints.

The label 'computer engineer' or 'software engineer' at least my experience was from when Universities were expanding the classic electrical engineering curiculum with a hybrid CompSci/EE program. Those 'Computer Engineering' majors would take the traditional first two years of common engineering (math, physics, sciences) but their disciple went to CompSci instead of further sciences for their later years.

I'll never forget when I was interviewing for university.. and I was sitting with the CompSci advisor and I asked "Ok, so when do you get to play with the hardware..." and he said "you don't...". I said "you spend 4 years at the keyboard?" to which he basically acknowledged as 'yes...' -- I then went right to the EE department and did EE instead

But by the time I was finishing.. the idea of Digital Signal Processing had expanded the power/reach/importance of programming over pure hardware. The number of 'software' jobs dwarfed the hardware guys which were becoming rarer and rarer.

I guess you don't work alot with contracted or offshored programmers?

There is a hell of a difference between the programmers that work off a boilerplate architecture and just try to modify it to fit the particular need.. and really don't understand the 'why' or consequences of a design... and the designers who made the choices prior.. or would make entirely new designs based on the needs.
You can take an architecture and hand it off to code monkeys would will build it. But if you just give them a set of requirements and don't oversee their actual designs, you can end up with all kinds of garbage that meets the spec, but is a mess upon itself. Modern computing and languages can cover up so much because of the almost unlimited amount of resources available to most simple applications.

With the insane higher level languages, libraries, PaaS, etc out there today, there are plenty of programmers that can build applications that don't have a snowballs chance in hell of doing the same without all the heavy lifting done for them. It's not just the distinction between a 'good coder' and a 'bad coder'. The stuff most people see as 'good' is the actual design work, or the creative that can analyze the problem for new solutions, or come up with new elegant ways, etc.

A code monkey can implement a spec -- follow coding standards, apply boilerplate methodologies, update/maintain existing code. But that doesn't mean they had the training, experience, or understanding to DESIGN what they are implementing.

So you started a discussion but don’t want to actually have one...

Sounds like you’ve seen it all, not sure why the rest of us are here

Depends alot based on the topic... But some simple examples would be protocol or interface design vs implementing a previous design. Or a similar concept close to my world... a codec. There is the math and science behind the design that can be completely independent of the implementation... but also must consider what is feasible in real world implementation. Market leadership can be the difference between an inefficient implementation of that format and a better one. Both implementations could interoperate because of the agreed upon formats and signaling, but can be night and day in efficiency based purely on ingenuity in the implementation.

Do your specs to your partner include just the requirements, or do you spec how its internally architected and executed as well? Do you leave those choices to simply someone who has shown proficiency in implementing a prior mapped out design, or do you look to someone with more advanced skillsets to architect the solution?

We have fellows that specialize in the research and innovation in the field... be it compression, protocols, security, cryptography, etc... we have architects who are turned to for their knowledge or proficiency in designing models for scale, resilience, performance, environment, etc.. and we have all ranges of people implementing both designs passed down and their own designs. The skillsets, values, and abilities for all these roles varies.

The background and comprehension of the guy that designed our h264 codec is far different from the team that excels at integrating it into a scalable platform that serves billions of minutes of usage per week... which is different from the team i can rely on successful implementing a client on a isolated host.

I don’t lump all that kind of work together under the guise of design and implementation being inseparable as you put it. It’s often a question of what level you are considering the design.

Even in simple applications- you can source out work to teams to implement a design that has already been laid out... architecture, data models, how the work would be broken up, etc or you can hand off a list of requirements for how the application interfaces and/or performance... leaving it to the team to pick their tools and design to meet the spec.

Some organizations are very hierarchical... others are more open to leaving designs to individual contributors.

It has been my experience we have very different skillsets roles out there and different roles. I have plenty of tasks we delegate and trust the teams to own all internal aspects... even the platforms and technology in use. But. We still have many more tasks that we can’t just leave to a coder who is proficient in implementing things, but maybe not good enough to own the larger design.

A practical construct that comes out of these realities is we have product baselines all our projects must be evaluated with to ensure individual teams have addressed things deemed essential to all of our products (crypto, licensing, auditing, access control, etc etc etc).

Everyone understands what you are trying to say about licensed engineers and their requirements... but the limits on job descriptions is not what you say they are. You can find private and public sector job descriptions all over the country using engineer in their job titles for roles that are not licensed PE or EIT roles.

Miami...
https://exterd.miamidade.gov/psp/GUEST/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL&Action=A&JobOpeningId=61578&SiteId=1&PostingSeq=1

Ga
https://www.indeed.com/m/viewjob?jk=128f815a4e8d9d98&from=serp

Cali
https://www.indeed.com/m/viewjob?jk=7986b3c967c78d16&advn=6642196552263593&adid=362368293&ad=-6NYlbfkN0DDN2zF_vJqgt_Kkhyqg_lrZaB6a1RPh_4YB401_OwIymyzEuOWaHYdAtmdG3Mv0y2y9Ns6Xdl0xE1uHSC5thBZNO8GBLled7uiyfemEdb7p4qeVjcM2pFrrMj9QnSnggr2g7VrvSWAwWjCzH1eJoJ1gdVA2PGGyoa9mKQl_RugsEXWVLHmB_pffPsndUnKmawquSNoWoVkuelOUAG9yNB0sXfCyrWG6vL6TfJ23IO9dGlfAUw6TOQfhn9p24JWUPOcTaXc9wx2tHlgw7ooWrRDab0H6J7WaxbbkzKPk8GxVw0SWof5K6codPdf2ha3oTliFHcSKbliAdT1ttfJWebQCEHuG3rZosw5BNQbV5Uke2YN8WKf9t9zr6YDU_vhhHo%3D&from=serp&dest=http%3A%2F%2Fwww.indeed.com%2Fjob%2Fquality-engineer-7986b3c967c78d16&desth=05dc2042bde1f04cc0b8ff9f03a05988&prevUrl=https%3A%2F%2Fwww.indeed.com%2Fm%2Fjobs%3Fq%3DQa%2Bengineer%26l%3DSan%2Bjose%252C%2Bca&tk=1er3fj85i3ohs000&dupclk=1&acatk=1er3fjea1u5d5802&pub=6917c08ec3ecf6012dd26f3773156e870cace3277f6b99df

Take your pick... these are a variety of fields that use the word

“Engineer” != PE and that isn’t a confusion like you claim

Well this gets to what i was saying about what level...
Now your Example sounds more like a component you know what it needs to do, so you start mapping out your approach. You mentioned using flow charts, etc. depending on the complexity of the task, this kind of stuff can be just someone’s “fingerprint” in they have their preferences/traits in how they tend to structure stuff. But what if its a bigger task...

We still try to map out how we will tackle the bigger problem and how those blocks will cooperate and interact to deliver the requirements. Will we use file based storage or db or memory... will it be stateless.. will it be monolithic... what will we reuse or have to roll our own...

Our last project was a new microservice that basically is a wrapper for a media sdk from another vendor so it could interact with an existing media infrastructure. So the architect mapped out the different processes and roles they would use to build up the service. All stuff the outside world never sees, but someone made a choice in how we move from raw frames to packetized RTP, or how identities would map between the disparate systems, to how we would generate and plug into the metrics platform, or what was needed dependency wise to build on a new host environment, etc.

Honestly in my world the actual “coding” portion is largely just taken for granted. It is expected everyone can deliver and build what is envisioned. For coding the difference really bears itself out in efficiency (performance and investment) and elegance. Code that is brittle, just doesn’t work, or no one else can follow really isn’t a topic. The layers of defense in terms of standards, code reviews, test coverage, integration testing, etc really keep a reasonable level of quality. The areas of contention and larger input come from “what” you are doing snd less about how it was written.

But that is why i made such the point between developers and code monkeys before. It is assumed everyone can make the light blink with reasonable code... the difference is in the thoughts and choices outside of the translation of ideas into the raw code.

You keep pooing on “engineering” inferring its some overlord trying to mandate constraints and planning verse you just flowing your ideas into code. I don’t see that mindset in any of our teams. People hate on overhead, too much planning, artificial constraints, and bad decisions they are forced to live with... not “engineering constructs”.

Our company has always been a “respect the doers” culture with a high level of empowerment. When we were acquired and now part of a 70k+ company i saw the stark differences in approaches. They were strictly waterfall... shipped 1-2 times a year... separate testing, docs, etc. we had been early agile champions... we were integrated scrum teams... we had good testing.. we were on short sprints.. we had daily build quality... we were agile in our planning. Luckily they lusted after the benefits they saw from our approaches and we have turned the much bigger ship. No we are not flawless... but in large part we have the right ideals and thoughts on what to value and what is waste.

But i still see the levels between different software guys... and its almost never about their raw code... its more about the decisions they make in what they build. Tho there are a few freaks of nature that are known for their ability to tackle idea to prototype at about 4-5x speed vs others

And that's the crux of it... there are key reserved phrases/titles - but it hasn't been excluding 'xxxx engineer' in ages. The PE role has been clearly separated from the generic word 'engineer' for a long long time. This isn't a point of confusion for anyone who has gone through any Unversity's Engineering college... and the Mechanical or Civil engineering programs weren't running around crying foul either.

We all knew Mechanical Engineering was the Pre-Business major anyway