itsmeste

I strongly agree, but JSDoc isn't "the cool thing". So it's left to be used by us, who care (and read their docs).

Context matters, and businesses all have their own contexts. But in general, what you refer to as "0.1x developer" is what generally is understood as the "10x developer", and your description of the "10x developer" feels more like overconfident and unguided jr-mid level devs.

It's easy to step into the trap of thinking lines of code written, or amount of commits pushed are a benchmark for a dev's productivity. Reality is, the greatest devs build a stable product that leaves everyone's pager silent even on peak usage, lets new contributors be productive quickly, and cause no blockages along it's development.

People (sometimes managers who read the comments) got mad at me for much less in the past.

Couldn't agree more.

I had colleagues with 20+ years of industry experience who couldn't communicate efficiently, extending every short call to 1h+ meetings, require long and recurring discussions for the smallest details, or define tickets that always had to be reworked. The same people were often off by magnitudes with their estimates and reluctant to suggestions to improvements in their tooling (i.e. linter plugins for their IDE when necessary).

On the other hand, I had teammates with ~5 years of industry experience who outpaced the whole team, delivered optimal quality, were empathic, held workshops for other devs, and still had enough time/power to work on things like refactors.

mutation createUser-v2

Seen that in some productive APIs, always fun.

Do you know of a good source of information on how to recognize any plant's nutrient deficiencies accurately?

Have those microservices use different patterns (language, framework, infra, etc), and outnumber your devs by a magnitude so everybody gets a piece of that sweet context switching, multiple times a day.

The last 5 years I found myself developing for companies having a bunch of nonsense "microservices" with totally ridiculous separation, which added more to their problems than solving them.

The common denominator of those companies is they all had no significant traffic, had their initial codebase developed by (unmanaged) amateurs, and were later managed by people inexperienced in software.

Due to the heavy resistance in all cases, I eventually became tired of proposing simpler solutions and the endless discussions around it, and accepted premature microservice architectures to be part of my infinite source of income.

Amen.

"How did you decide for TypeScript, and how do you benefit from it" is among my first questions in interviews for TS positions. It's ironic how rarely I get a good answer, but it offers a good insight into their tech philosophy, and mostly I'd pass on the position. (working in backend)

I found synergies in many cases. As D13Fd said, legislation is very similar to code, with many intertwined sections, references and conditions. You'll need a sense for detail if you want to find ways to push the right of your client through court.

Similar to the backend/frontend specialization in coding, a lawyer may specialize in a certain sector. Reading through the legislation is quite similar to reading through a legacy codebase, and writing notices is somewhat similar to structuring and crafting new code, which will always be based on the same 'framework' (if you work in a single country).

Especially in cases regarding data protection, as a SSE you'll always have a good advantage over many of your peers, as you'll easily identify nonsense and can often provide in-depth investigations.

I'm slowly getting into law while working my 16th year in tech. It's about the same salary, and instead of reading books worth of technical docs, you read books worth of legislation. The good part is that legislation isn't changing as frequently as technical docs, so you're not required to invest as much of your spare time to stay up to date as a SSE does.

This. Probably every TS codebase I ever worked in had zero to none function- or inline docs with people always claiming "documented by TS". I call that BS, and you can see that in their projects. "Typescript codebase" became the equivalent of "generic low quality codebase" imo.

I'll never understand why people need a programming language inside a programming language and refuse simplicity (i.e. using jsdocs, which has perfect IntelliSense support).

I was using Slack to manage notes on my personal research projects. I never used any features besides channels, messages, and search. I loved it's UI, rich-text features, accessibility, and reliability. Amount of workspace messages after 5 years is 1154. Besides that, I'm using Slack's business+ plan in the corporate teams I'm leading.

Again needing to migrate from a once great app that's now getting ruined by Salesforce, again with no complete export features available, I start feeling ridiculed.

Zulip looks promising, and they even support good imports from Slack. However, their UI just feels too cluttered with all those borders around messages, and their rich-text support isn't as convenient as Slack's.

A majority of my team members felt the same, and we decided to spend a day for hosting an internal contest to build a basic alternative to Slack that we happily migrated our personal workspaces to.

What Slack could've done better: - Saving money at other places than the most critical one for backwards compatibility, message retention - Store messages locally, instead of on their servers - Offer complete exports - Don't advertise this change as "beneficial for free users" - As a last resort, offer one-time payments instead of a per-user subscription model

When Salesforce bought Heroku back in 2011, it was pretty clear Heroku would become yet another dead product that once was an absolute great piece of software.

Why? Commercialism.

Founders sell to the highest bidder to make their exit worthwhile for themselves, not caring about the future of the product (and customers).

It's a no-brainer that a commercial company like Salesforce (it's in their name!) doesn't have what it takes to build AAA software, but focuses on maximizing their profit. They drove away their best staff, focused on the wrong features, and are seemingly overwhelmed by maintaining their purchased software, all while probably not even realizing their demise.

We should all come to the agreement that takeovers of fundamental software by incompetent companies should be seen as a hostility towards every current user of said software.