4 ms·
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 o
by cookie_monsta 5y ago
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.
- fartcannon 5y agoUp until about a year ago, IC meant independent contractor to me. Individual contributor sounds like a human resources rebrand for lower pay or power.
- imperfect_light 5y agoPrincipal 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"
- xen0 5y agoHow about a label given to a track that runs parallel to manager?
- Juliate 5y agoDepending 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.
- bspammer 5y agoIC to me means a developer who has no interest in managing people.
- redeux 5y agoI’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.
- bin_bash 5y ago> 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.
- dsjoerg 5y agoIt 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.....
- bin_bash 5y agoCalling someone a “software engineer” also doesn’t clearly communicate they are not managers.
- coldcode 5y agoAt my last job my team were at one time referred to as "onshore resources" despite all being employees and in the same office.
- hbarka 5y agoAn 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).
- stinos 5y agoI 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).
- cookie_monsta 5y agoExactly. Remove (or define) the jargon and this could be a piece that would resonate with any sort of project manager.
- xerox13ster 5y agoPeer Review
- austincheney 5y agoI 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.
- cookie_monsta 5y agoI'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.
- nebs 5y agoAlso 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?
- skydhash 5y agoIt'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.
- bdavis__ 5y agoyou 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.