nrawe · HackerTrans

2개월 전discuss

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.

nrawe

3개월 전discuss

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.

nrawe

3개월 전discuss

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.

nrawe

4개월 전discuss

> 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.

nrawe

5개월 전discuss

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.

nrawe

7개월 전discuss

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.

nrawe

7개월 전discuss

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).

nrawe

7개월 전discuss

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.

nrawe

8개월 전discuss

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.

nrawe

9개월 전discuss

Many hours of fun it was running CounterStrike servers and writing my own plugins. Halcyon days :)

nrawe

10개월 전discuss

I agree the problem, but the given solution feels a bit clunky to me. From a syntax perspective, passing an options object and applying it over a set of defaults feels a lot cleaner. The reason kwargs work in Python is primarily because the syntax is clean on both the caller and callee's side of things. This puts a lot of additional non-obvious syntax on the callee side.

nrawe

10개월 전discuss

It's a great message, thanks for sharing.

nrawe

10개월 전discuss

This really made me laugh, thank you :)

nrawe

10개월 전discuss

I think you hit the nail on the head: React is a good fit for certain solutions (like interactivity rich web applications), while not a good fit for others (like adding minor interactivity into a form). There are trade offs to React vs Vue vs Angular vs Vanilla and which is best is contextual to the problem you are solving, rather than a more moralistic "X is THE winner" stance.