I'm on a project that breaks even + some pocket money. I don't see a meaningful way for incremental refactoring, because that would increase code complexity for a long time until the incremental refactoring is finished. Any refactoring has to be done in a big-bang approach, but the PM said the project isn't generating enough money to fund that downpayment.

Politics, people talk too much, but nothing gets done and no one will take responsibility for it in the end.

Not sure if it's interesting to tackle. ;)

On a more serious note. I think that a lot of product production processes can be optimized way better than they are now. Especially in large companies, where people have become conservative. They think the current way of working is the most efficient, and aren't looking for more optimal ways to produce their products. I think there are some general methods that work in almost all companies that could be made into more general software solutions: e.g., tail analysis, logistic optimization, item clustering, similarity analysis, etc...

Lots of things are most companies are horrendously inefficient. However, unless those things are a bottleneck, optimizing them doesn't help much.

A good problem: growth in headcount, more teams, more communication required, less you can know all that is going on.

Hey, I am actually working on something in that vein. It's still pretty early and I am looking for calibration on what people find useful.

https://closedloops.co

Any feedback or thoughts appreciated. :)

It's a browser extension that you link to multiple services (currently just Figma, Google Docs, and GitHub) then you can correlate different work items (a Figma sketch (?), a GitHub PR and Google Docs, any amount of them) then you will be able to see comments from all of them in one place, the extension, regardless of which work item you are on.

The basic idea is to expose engineering thoughts to design to product so everyone sees everyone talking without add'l friction.

So say design is discussing changing something, the engineer(s) on the project would see it in their context of GitHub.

Feedback:

Idea - I think it is a good problem to solve, for us it would be Slack + OneNote + JIRA + Github mainly. How to solve that problem (should it be an extension, software, or just good human process) I am not sure. I think there is value in the process of writing stuff up manually to a common place (such as a wiki) because we all know that when you start translating the problem into words, you often realize that you don't fully understand the problem!

The landing page is a bit thin for me to go further. It has big generic promises, and then the next step is to sign up. For me that is too much friction. Before I sign up I want to know exactly what you are offering and how you are solving the problem.

What you have done here is very very common in landing pages, even big companies with massive investments do it. They promise these "emotional benefits" or "vague technical benefits" and then want you to sign up based on that.

It costs me $100 to try anything out, even if it is free. That is the cost of my time. So to get me to spend that virtual $100 I need specifics, or I need to know your brand or something so I don't need specifics because I trust the brand.

I can't think of a software example off hand though where I trust the brand that much, such is my cynicism! Maybe Apple for hardware would be an example.

The application getting more complex and developers not stepping up in terms of skills/knowledge.

I recommended rewriting the whole terraform infra code base in Crossplane sarcastically in the interview but my manager might be taking it seriously enough to want to see it implemented as a POC.

I work in a hazardous industry. To meet internal and regulatory standards, we really need a certain level of engineering capability.

But the company has been hellbent for several years on diminishing the number of engineers and the influence that engineers have, and we are just on a slow march towards the next major accident. But until somebody dies, nothing will really change.

The salami-slicing reduction in engineering decision-making authority also means that there is no path to escalate issues.

There's a discontentment felt by every engineer in the organisation resulting in cynicism and disengagement, and yet to hear the upper management speak, we are all bursting with excitement at what exciting times we are living in, and relishing the diversity and inclusion.

Trying to find ways to look busy so that I don't get assigned more projects.

99% of the problems I face personally is some variant of how do you take a team of people with differing levels of ability and not have them perform at a level of the lowest common denominator in every skill category?

I don't know what the answer is but I think code reviews are fundamentally broken. They need to be more dynamic and more intelligent, simply requiring a code reviewed by someone is close to worthless.

If I'm the JavaScript expert then I should be able to tag myself as such so I know about every piece of JavaScript that's going into the codebase before it's merged. But more importantly, if I'm the expert on some section of the codebase I should be able to "lock" that code to myself in such a way that any changes to that code must first go through me.

Maybe this kind of thing is already possible, but I've just not seen it. Half the time code reviews are worthless because it's one dev who doesn't really know what they're doing reviewing code of another dev who doesn't really know what they're doing.