What happened to me is I passed a date to an external library, and then after that library did its work, that date was changed. Super annoying even if you know that it's a mutable object.
That almost sounds insulting. Like management is the only party with vision, drive and a goal and everybody else is just there to help. When often management just manages and true innovation really comes from people of all positions.
On the contrary, it is a helpful term. Before the term, it was common to ask "are you a manager", and then you were defined oppositionally, as not-a-manager.
Whereas IC having its own identity means it has many positive connotations. "I'd much rather be an IC, so I can get things done" etc. You can still be very senior without having direct reports or having to do line management, often seen as a necessary evil.
In my reading it makes it easy to even spin managers as the bad ones: ICs contribute individually and directly something of worth. Managers contribute only indirectly via ICs.
The term isn’t used to define everyone who isn’t a manager. It’s used to define people like Lead and Principle Engineers who are a subject matter expert, have influence in defining a project, but have chosen to continue in engineering roles rather than switching to management. Often their position in the company is parallel to the managers rather than subordinates, hence the “individual” part of the term.
This requires the intentionality of the organization though. They seem to default to managers make the decisions. Ideally, managers manage people, IC execute and you get the "right" people in the room to make decisions, regardless of title or track.
> This requires the intentionality of the organization though. They seem to default to managers make the decisions.
if a company doesn’t intend to utilise IC then they don’t have ICs, just regular software engineers.
An IC is only an IC if the organisation is structured to utilise them as an IC. It isn’t a job title, it’s more to do with how an individual is utilised in a company. It’s their placement in the org structure.
> IC execute
IC plus engineers execute. IC are a subset of engineers.
As @hnlmorg mentioned, the term is only typically used for people who are at a level where they could be managers, primarily supporting others, but are instead still contributing directly themselves. It's almost the opposite sense from your "insulting", in my experience.
SME and IC are functionally different. SME informs, IC creates. Often, IC aren't SME in the space they're developing in, because they're SME of the technology instead of the business.
That's fine to do that, but kind of pointless. Everyone is then a "SME" in their own job space and thus the term is kind of useless. So, just replace every mention of SME outside of your company to "Business SME" instead of "Technology SME" and you'll understand what we're talking about.
Or, if you truly do not need anyone but a "technologist" to deliver product, you must work in a pretty simple business space! I work in healthcare and our PhD's and MD's have a very, very different knowledge space than I do, I and I deeply respect their contributions.
This whole thing reminds me why I never wanna work for someone again. From what I saw at Google it all just ends up being classist top-down BS of who isn't allowed at the big kids table, or bottom-up BS by insisting they aren't the SME just the IC and we can't do anything until the XYZ PM SME TL and/or manager approve.
It is unparsable Dilbert nonsense to anyone outside of specific scenarios. And it causes interminable discontent. Because what if the SME is the PM because they know business and tech but the SME is actually the IC because they know the tech and its tech but what if the manager is actually the SME because they're running the tech and may need to redelegate if the IC needs vacation, blah blah blah.
(job history: college dropout waiter => my own startup, sold => Google for 8 years => my own startup)
I'm sorry you've had bad experience working with other people, but in my experience as a developer, having multiple SME's available is indispensable to real alignment and fast development. I've primarily worked in startups, not big companies, and have often worked in healthcare. In healthcare, you get beyond your "I'm a big smart engineer" ego BS and you are willing to listen to the PhD's and MD's that help inform clinical workflows. From my perspective, I would never ask a clinical researcher or a doctor to understand our react app, and they aren't going to ask me to have deep understanding on medical details and clinical workflows. We work together to deliver high quality useful software quickly.
My PM SME validated my workflows and I found Jesus in them then my MBA TL PhD…bla bla bla.
A human being who avoided corporate brainrot just writes “I worked with John and he was indispensable because (insert reasons you wrote here)”
I’m 37 and never heard of this acronym. That’s the entry-level version of my point. Not that other people hurt me or people knowing things is actually bad.
True. It is part of the general industrial ritual of reducing workers to a number or a letter combination. That way, managers reduce the emotional attachment to the people, and they can fire them more easily.
If, instead, you would be Tom, Bill and Biff, there is a risk that the manager would build attachment, and make it harder to treat you bad. If you're IC1, IC2 and IC3, you can be exchanged like machine parts when you break, without anyone crying.
No that’s not really how it works in tech at all. There’s a deep recognition that individual engineers (and other functional practitioners) have important knowledge and expertise that is essential. Of course you do need some overlap and redundancy so that people can take sick days and avoid the wheels falling off through attrition, but competent shops aren’t ever treating people as numbers. To the contrary good ICs are widely recognized as being much less full-of-shit then management.
I'm still using it to distribute/update production apps and whilst the script language is a bit funky, it works reliably. And the tools work under Linux too, so I can easily integrate a "create setup" step in the CI/CD environment.
And start with simpler regular rules and get more complex over time as words are imported and reimported, pronunciations shift, grammatical rules morph and evolve (often to simplify grammatical genders and cases) while leaving their mark, and spelling changes.
For example, goose/geese is the result of the plural form and singular form undergoing different paths in the Great Vowel Shift resulting in the different vowels in the modern form.
There's also evidence that Proto-Indo-European had laryngeal consonants that have disappeared in all modern languages derived from it [1], but have left their mark on the descendant languages.
This. A language that doesn't adapt (accumulate shitpile of baggage from other languages over changing times) will be a dead language eventually.
English will always have my respect for being open/inclusive and adaptive.
Interesting fact: If you are looking for a spoken language with the cleanest/composable grammar - it's Sanskrit. The panini grammar is actually like a programming language where sentences are just compositions of lower level similar units.
But like I said it's practically dead (not used as a spoken language). But interestingly used as a proxy language for translation and other nlp tasks due to it's clean grammar :)
I have been saying it since the beginning that we are centralizing all the power of the internet to one organization and that this a bad thing, yet I get downvoted every time. One organization is going to have a say on whether or not you can have a website on the internet, how is this objectively a good thing?
I'll upvote you for at least asking the question. But you get downvoted because your premise is wrong.
There are lots of organizations that support the ACME protocol. LE is the most well known, but there are others, and more on the way.
Existing CAs don't necessarily vanish with this change. They are free to implement ACME (or some proprietary protocol) and they are completely free to keep charging for certificates if they like.
The real result of this change is that processes will change (where they haven't already) improving both customer experience and security.
But to be clear there's no "one organization" in the loop here. You can rest easy on that front.
Maybe you get downvoted because this isn't centralizing all the power of the internet to one organization rather than being downvoted because people don't have an issue with that.
The CA/Browser forum has massive power over the web whether you like it or not, because they make the browsers. And make no mistake, it's the browser representatives that are the most aggressive about tighter security and shorter certificate lives.
Every project I've come across that uses an ORM has terrible database design. All columns nullable, missing foreign key indexes, doing things in application code that could easily be done by triggers (fields like created, modified, ...), wrong datatypes (varchar(n) all over the place, just wwwhhhhyyy, floats for money, ...), using sentinel values (this one time, at bandcamp, I came across a datetime field that used a sentinel value and it only worked because of two datetime handling bugs (so two wrongs did make a right) and the server being in the UTC timezone), and the list goes on and on...
I think this happens because ORMs make you treat the database as a dumb datastore and hence the poor schema.
Honestly database schema management doesn't scale particularly well under any framework and i've seen those issues start to crop up in every org once you have enough devs constantly changing the schema. It happens with ORMs and with raw SQL.
When that happens you really really should look into the much maligned no-sql alternatives. Similarly to the hatred ORMs get, no-sql data stores actually have some huge benefits. Especially at the point where db schema maintenance starts to break down. Ie. Who cares if someone adds a new field to the FB Newsfeed object in development when ultimately it's a key-value store fetched with graphQL queries? The only person it'll affect is the developer who added that field, no one else will even notice the new key value object unless they fetch it. There's no way to make SQL work at all at scale (scale in terms of number of devs messing with the schema) but a key-value store with graphQL works really well there.
Small orgs where you're the senior eng and can keep the schema in check on review? Use an ORM to a traditional db, escape hatch to raw SQL when needed, keep a close eye on any schema changes.
Big orgs where there's a tons of teams wanting to change things at high velocity? I have no idea how to make either SQL or ORMs work in these cases. I do know from experience how to make graphQL and a key-value store work well though and that's where the above issues happen in my experience. It's really not an ORM specific issue. I suggest going down the no-sql route in those cases.
NoSQL is even worse, data gets duplicated and then forgotten, so it doesn't get updated correctly, or somebody names a field "mail" and another person names it "email" and so on...
There is zero guarantee that whatever you ask the database for contains anything valid, so your code gets littered with null and undefined checks, and if you ask for example a field "color" what is it going to contain? A hex value? rgb(), rgba(), integer? So you need to check that too.
In my experience NoSQL is even worse, they are literally data dumps (as in garbage dump).
reply