nrawe

I get the anger; I think this is misguided. I know this will be distinctly unpopular (bye-bye karma!)

SWEs in general have been paid significantly higher salaries for decades in part because of the skill level needed and that they are generally working on capital projects (build new thing) vs operational projects (maintain thing built). It's the difference between needing a Landscaper to come in a completely reshape a bit of land for £10k once, and Gardener to come in a mow/prune once a week for £10. Most salaried SWEs don't necessarily see that every project they work on is a new patch of land to be landscaped; those who've contracted do.

SWEs have been effectively paid this "danger money" because of that inherent volatility in projects being shut down, which has been there since the dot com bubble but is now amplified because of the relative size of the tech sector.

The skills barrier which has been eroded in part by the lack of professional standards (anyone who can edit a PHP script can call themselves an SWE vs a Chartered Accountant which has to be certified), and now explicitly because of AI.

In some ways this just looks like "FOSS for Angry Millennials" without the understanding of the further damage that this will do to them and their industry. These are the forces its trying to get revenge for: (a) high inflationary creating risky environments for businesses to navigate, (b) tax changes which have impacted how organisations pay for SWEs, (c) AI offering "efficiencies" in all parts of the value chain, (d) the demand for ever-growing returns by shareholders as we enter the end-state of neoliberalism.

None of that is improved by this movement. Regardless of what you think of them, the original Occupy movement made it impossible for the people responsible for the crash to not be aware of/somewhat put out by those impacted by the crash. This is Just Another Open Source project. The way for those impacted is: (a) keep their skills sharp by helping charity projects that need the volunteer support; (b) get active politically on a local level; (c) use the time to start their own businesses with others.

There is a firmament that is needed on which all tech grows like Linux which is a good thing. This is not good for the Landscapers or the Gardeners, nor does it fix the issues which have led to the layoffs.

It's the same level of testing for us for either Python2->3 or Go (it's a legacy code base, low automated coverage).

Conversion is now (somewhat) easier, the testing will be the slow part. For the speed improvements, which we also need for a migration from on-prem to cloud, it's a no brainer vs the other options at our disposal (like GraalPy).

Yes, sorry, typing fast - we knew Go would be faster but not quite on that scale.

Doing it currently, Python to Go. Early indications are a 50-98% increase in speed (e.g. one testcase went from 26hrs to 30mins) for network/CPU heavy workload. Conversion via Qwem, lots of testing needed but compute savings will be worth it.

I don't think this goes far enough -- its a best case scenario.

There is no Utopia for mankind at the end of an AGI that is the labor force because people need a purpose; without that, degenerate behaviours and vice are easy to fall into and the spiral is not big. The state of the human race - particularly the internet-native generations - is a testament to that.

The only way the AGI Utopia works is with a massive reduction in the human population with a Spartan/Helot relationship between those remaining.

Let's face it, the people who want AGI so badly aren't the wam cuddly people who want to feed the poor, house the homeless, and cure the sick. Their motives here are not pure...

A company I worked for has run VFP up until the last few years. I cut my teeth professionally with it on ETL processes. It moved data around like nobodies business!

This mirrors my own thoughts. Additionally, for businesses looking to replace people (particularly developers) with agentic AI, this is arguably worse from an accounting perspective as the cost of using these services will likely be pure OpEx vs capitalised per my understanding of US/UK GAAP accounting.

My pet theory here is that Anthropic wants to be the end-to-end system for all software delivery on the web, with its model firmly at the centre of that universe. I have seen posts (but not confirmed) that as part of their recent breach was part of a Vercel-like clone. From that POV, Atlassian could be useful for a few reasons:

1. Data, forget Jira tickets, but Confluence and Service Desk could be valuable for requirements shaping on the model. 2. Customers, as it's easy NRR to include on their balance sheet and would help with an IPO. 3. Infra, Atlassian has been remarkably stable for the last few years (in my region at least) while Anthropic have been suffering, maybe there's some ops acquihire advantage.

For the love of god, don't be true, though.

This is an excellent and distinctly frustrating game Echo comments on restart being faster; maybe having the % stats in the main ui somewhere. Will be recommending this to some friends.

> The average knowledge worker maintains accounts across system after system, switching between applications hundreds of times per day. And they produce, in aggregate, a staggering amount of coordinated and collaborative activity that never actually becomes anything resembling ~output.

The problem with this is conflating *output* for *impact*. A team of lone wolves writing 1k LOC by the hour is good output but not necessarily good impact.

A team with higher coordination overhead and "structural support" will probably have lower output, but if it focuses on significantly higher leverage activities might just have a better impact. The key question is whether that impact is visible and understood (often not) and lots of businesses are bad at understanding leverage.

I see this lone wolf BS from lots of founder types who mistake their own grind for real performance, often missing their own blind spots. I don't disagree that the 80-20% rule comes up and that some people have an outsized contribution overall compared to others, but to say that collaboration is dead as a result is throwing the baby out with the bath water.

I've not heard that goal before. If true, it makes me sad to hear that once again, people confuse "More LOC == More Customer Value == More Profit". Sigh.

As the manager is accountable for the problem being solved, they are responsible for making sure processes are optimal.

There definitely should be an onus on individuals and teams to reflect and generate their own improvement actions to that end. Scrum Retros are a good example of this. In this case, the manager is responsible for process improvement by chairing the retro, ensuring that the team has the info needed, and has the space to implement actions. Scrum Masters chairing retros can be seen as a form of coaching.

There are also times when process improvement means directly stepping in and directing the team to do something differently. This can happen for lots of reasons; one example may be a manager taking over an existing team under fire and identifying immediate changes needed to dig them out. I've seen several teams with entrenched mindsets in this situation where process improvement is directed rather than discovered.

Ideally, the team drives it, while the manager is responsible for ensuring it happens successfully.

E.g. there is a big difference between "Why did we loose a day here, what can we learn?" vs "From now on each dev needs to review every pull request twice per-day". Might be the same ultimate action, but in the latter the manager is solving the issue directly.

Depends where you go, these two terms get used interchangeably (incorrectly IMO) and so there is some semantic drift.

If you were to read Julie Starr's "The Coaching Manual", or "The Coaching Habit", the definition is more or less what I outlined.

If you are familiar with the Leadership Continuum/Situational Leadership, the distinction from there becomes: tell/sell (mentoring), join/consult (coaching).

The Coaching Habit is a fantastic book and is the right way to do. Managers don't exist to solve other peoples problems; it's vice versa.

Managers are accountable for a problem, and responsible for building a team that can solve it in the most cost effective way. Their team members are responsible for solving the problem. Managers are also responsible for a lot of other things (tracking, reporting, cost management, roadmaps, change management, hiring/firing, process improvement). IME the managers who don't like the coaching side largely don't really want to be managers or don't understand that distinction in responsibilities. (Not helped, TBF, by lots of pretty awful promotion schemes that don't support people on that path).

What The Coaching Habit does leave out is the need for mentoring. Mentoring is not a synonym for coaching, it's active: "my report does not know how to do this thing, I need to tell/show them how to do it." While coaching: "my report knows how to do this, they need a soundboard for getting to the right answer."

It can distinctly suck some time, for both parties. However, in the long run, when managers stop coddling, their team members start growing. One person who hated me bitterly when I started on the coaching road with them now thanks me for it because it helped them to build their confidence and ultimately their skills to become a CTO. I have similar stories from others. YMMV.

I agree with some of the points here, but I roundly disagree.

Agree with: people are employed to do a job, they should be empowered to get on and do it with minimal supervision, escalation, and distraction (particularly from "PR Theatre"). Also agree that sometimes unity of vision and focus time can yield exceptional results.

However, this doesn't work unless you can work every part of a system with a high-level of alignment with vision and commercial context to make good decisions and you test mercilessly. I know, have worked with, and still work with, an "entrepreneurial developer" type who can do that, but over time their "isolationist" approach leads to misaligned features that are usually anathema to good by the end of the startup phase.

Additionally, the ability to work with that level of alignment and autonomy simply doesn't describe the majority of the developers on the market and who really just want to be given tasks in their area of skill. Are they acceptable for a startup? Probably not. But in the SME context that's fine because collaboration fills the gap.

Also, while there is a lot to be said for T- and V-Shaped engineers, I-Shaped engineers are much more common and that's not a bad thing because – if one can get a designer, fe, be, and operator collaborating _effectively_ – you can still get good results.