Comment by cookie_monsta | Hacker News Reader

Comment by cookie_monsta | Hacker News Reader

I am not a software engineer so I am obviously not the target audience here, but I do like reading these types of articles because sometimes they have nuggets of wisdom that can be applied to other fields.

Having said that, I would make the following points to writers who wish to engage outside of the narrow circle of their profession:

* It's nearly 250 words into this piece before we even get a hint that we are talking about software engineering here, and even then it's only because the writer mentions a PR. I know enough to know what a PR is, but a general audience would not. It's not until some 620 words into the article that software is actually mentioned and the general reader can say without a doubt that software engineering is what we are talking about here.

* Along with PR, IC is something that is never defined and this one was new to me (and a little tricky to search, but I now understand that it is an Individual Contributor). The PRD was easier to track down, but again not obvious, even from the context.

Again, I get it - I'm not the audience and this is a bit of industry in-talk. But I think it's something that worth thinking about - you don't have to dumb down your ideas for them to be understood by a much larger audience than your immediate colleagues.

Up until about a year ago, IC meant independent contractor to me.

Individual contributor sounds like a human resources rebrand for lower pay or power.

How about a label given to a track that runs parallel to manager?

Depending on the place, it can mean different things. I've seen it also mean "team member" or used for senior engineers whose roles (navigating across different teams on short/mid-term important/investigation/transformation projects not necessarily visible on the official R&D roadmap) makes it difficult to attach them to a particular team/specific role.

The people and places that handled well this level of fuzziness do so _thanks to_ a good amount of trust, care and shared vision.

IC to me means a developer who has no interest in managing people.

I’ve understood IC to mean individual contributor for over a decade. I think the industry just over uses acronyms and as a result you end up with collisions.

> Individual contributor sounds like a human resources rebrand for lower pay or power.

I’ve been in companies using this term for the last decade and definitely do not think this is the case. If anything it’s a movement to empower people that don’t want to be on a manager track by offering them a precise term to describe their track.

It simply means people with no direct reports.

It means someone who is not a people-manager. That is, someone who _contributes_ to the team/company by actually doing things, rather than by supporting/directing the work of others.

Trying to think of other words for this... programmer, software developer, software engineer. But those words are all role-specific. IC has the advantage of conveying that the person is not managing, but is generic with regards to role. Non-manager works, but that emphasizes the negative.

Hmm.....

Calling someone a “software engineer” also doesn’t clearly communicate they are not managers.

At my last job my team were at one time referred to as "onshore resources" despite all being employees and in the same office.

An IC is a role without positional authority but the company will indoctrinate you with “lead by influence” internal training courses and tell you that you can effect change purely by your charm and will question why you can’t get that person or department to solve their bugs. It’s all part of the we-are-a-flat-hierarchy mantra and you know we are all equal (in skill, drive and initiative).

Principal engineer roles are pretty desirable. I know a number of managers of engineers who wish they had gone a PE route rather than a management one.

I know very few PEs who say "Oh, I wish I had a whole team to manage, worry about hiring/retention, reviews, administration, etc"

Also not a software engineer but I do believe that software engineers have a very good workflow. I've been trying to figure out what the equivalent of a pull request could be for non software engineers (like hardware development). Is anybody aware of people who have tried to do something like this?

It's the merge part that is an issue. PR works on text files and on the line level, which fits code perfectly, as most statements are one line. For prose, it's messier. In other media it's difficult because of the cohesion of purpose needed, or just that you can't merge easily. It's easier to cooperate on the person level, than on the product level.

you write an ECN (Engineering Change Notice). these stack up against a given part number (controlled by a drawing). then the drawing gets updated. this is where any conflicting ECN's get discovered.

Note: ECN's were how things worked when you had a draftsman. Most engineers do the CAD themselves nowdays.

I am not a software engineer so I am obviously not the target audience

Still, what is said here really applies to any type of engineering. I've encountered pretty much everything mentioned both for software engineering and electronics and mechanics. Just replace the software-specific lingo with their generic principles (e.g. PR = review by others).

Exactly. Remove (or define) the jargon and this could be a piece that would resonate with any sort of project manager.

Peer Review

I am not sure this behavior is limited to software. While this behavior occurs commonly enough to qualify identify from repetition I would also say it’s not the most repeated or worst behavior I commonly see from software developers or other professions.

I'm unsure what you're responding to here and I definitely don't know what "qualify identify from repetition" means, but I wasn't singling out software developers or saying that using jargon is the biggest crime on the planet, just suggesting how TFA could have been better.

Reply on news.ycombinator.com