davetron5000

If you don't do a ton of CSS but think you have a handle on it…this survey will dispell you of that notion :) Never felt more dumb in my life than answer "never heard of it" to most of the questions about different CSS features.

We used this at my last company. We backported decisions into them as documentation. People sometimes referred to them, but not often. It was hard to take what was a huge list of docs, some of which had been obviated by others, and truly grok them all. But I don't have a better idea for how to solve the problem. I would say it worked OK, but not great.

The downsides is when you need to do something cross-functional it requires a different approach. What I have seen work is that you spin up a temporary team to own the delivery of the cross-functional project then have VP/CTO give all teams priority about helping the cross-functional team, e.g. the x-func team will say "I need support from finance and marketing" and those teams would agree to help out via 1 dev for 2 quarters (or whatever).

It requires a lot of clarity from management and agency from the cross-functional team.

At sub-100 developers, what I have seen work is to align dev teams based on company organization structure, so that each part of the company has a dev team to support the internal products they need and can develop expertise to help when coordination across teams is necessary.

The size of these teams is commensurate with the priority of the function and its internal products.

Like any organizational method, you need a strong vision from the top, clear priorities, and a product roadmap that makes sense.

I set up CoPilot with neovim and am using it on a few projects. The domain and architectural style of these projects isn't common. Asking it to generate entire functions seems not very useful.

But, when asked to either suggest the next line of code or complete a partially-typed line, it has been pretty useful if it is following a pattern established in the code already. Here are two examples:

Testing:

test "record creation" do

  record = create_record("Pat", "This is a description of Pat")

  expect(record.name).to eq("Pat") # I typed this
  expect(record.description).to eq("This is a description of Pat") # CoPilot suggested this
end

It's pretty good at this part of it as long as there is a pattern

Repetitive stuff based on common things:

COLORS = [
  "red", # I typed this
  "orange", # CoPilot suggested this
  "yellow", # CoPilot suggests this after I accept the previous line

  # and so forth

So, asking it to come up with something out of thin air is usually worthless, but it has been helpful at automating repetitive tasks that are somewhat small and not really places where a library or abstraction would be better.