Some great comments here. Tangentially, I occasionally day dream of running or working for a company that flips typical corporate “intention” on its head – Specifically by placing employees at the highest place of priority and let profits, progress, customers, share price etc. be what they’ll be. I think that would be a very interesting experiment.

As far as how that relates to pay, part of the experiment would be to pay each employee more than they are “worth” to market. Just to see how it changes things for them and the company.

At the same time, “freeloaders” and folks that just can’t cut it would need to be identified and separated from, to protect those that recognize and appreciate that the company is truly looking out for them and are reciprocating with true hard work and value creation.

Ya this article was great. I wish I could convince my coworkers to take a deep dive into Git. I do it probably once a year and it’s helped me be the “hero” with confidence several times.

Git is exciting/interesting to me…it is not normal.

I just took a stab at git worktree at work this week after rereading this article. It’s amazing. We were in the process of upgrading our UI component library and I was able to checkout pre/post upgrade branches without having to continuously npm install to swap between dependencies.

Plus I’m pretty sure I could have both “versions” of our repo locally running at the same time so I could do UI comparisons…but I didn’t actually get that far.

I’m going to be honest. I like this thread. Not only is the article long and “thorough” (whether you agree with this form of thoroughness or not) but the responses are too.

I can appreciate what the author is trying to express. I also related to how he’s trying to express it because it’s very similar to how I try to explain my opinions, shower thoughts, meanderings…which typically earns me eyes glazing over from my conversation partners haha.

I have many many thoughts on everything being discussed here, but rather than contribute, I’m going to sip on my coffee and keep reading.

P.s. I’m liking PD better than Reddit. Actual conversation happening.

Nice! Is this your first dive into programming?

Hm. In that case, smaller more frequent breaking changes may also not be ideal. It sounds like no matter how small the breaking change, everyone who uses the library is going to have to update their code… and if it’s happening frequently, that could get annoying.

This may be completely off-base, but just going off of what you said about data traversal, would it be completely out of scope for your library to provide a consistent interface for getting/traversing the data it is responsible for? Or do the consumers all use/traverse the returned data in very unique ways such that you couldn’t really develop a “general” API of sorts.

Context:

I’m a dev that consumes company wide libraries, not an author of such libraries. So the following comes from that perspective.

A couple questions:

1. Is development and consumption of your library happening in parallel? It sounds like you use the users to vet new features or major changes… is that correct? (They are iterating with you and reporting back on issues or desired changes)
2. Is your library made up of a group of isolated components? Or is it a library that does one or two major things and so a breaking change literally changes the whole of what the library does?
3. How are the consumers of your library when it comes to adopting changes? Do they readily do it? Is there a good bit of inertia?

My thoughts:

First off, SemVer is definitely going to be important. Also, it sounds like you’re working toward API stabilization which is going help iterating in the future.

My idea 1:

If your library is made up of several isolated components, what about doing major releases (ex 2.x.x -> 3.x.x) more frequently? Only include a small subset of breaking changes for one or two components rather than jamming a whole bunch in there just because it’s a “major version release”. The result is you could move quickly and iterate while also minimizing the impact on ALL of your users every release. Some of your users may be able to upgrade to the latest without having to touch much or any of their code.

My idea 2:

Do frequent major release (ex 2.x.x - 3.x.x) but always start with an “alpha” release that early adopters could implement and provide feedback on. This would shield the majority of your consumer’s code from having to iterate frequently but would also require you to enlist a group of committed early adopters that are diligent about iterating their code as often as you release.

Feedback on the original option 1 and 2

Option 1

This could work if your users are excited about your releases. But, it could result in people NEVER upgrading because it’s too much work to do so. (I’ve seen this happen. No one upgrades until they absolutely have to.)

Option 2

Depending on the size of your company, this will be a lot of work for you and will slow you down. If you’re using your users to vet out new features, then everyone is going to have to iterate frequently (like you said) if experimental changes don’t work out.

I’m a little surprised specialist was bad. Unless bad egos were involved.

In your experience, is success dependent on each member (or most members) being T shaped?

Have you witnessed/experienced this in action?

I just did a really silly loop (I’m on my phone) and it seemed to work.

@for $t from 1 through 2 {
  .a-#{$t} {
    color: red;
   }
}

deleted by creator

How are you compiling?