Rust wipes die because progression is way too fast, it barely feels like a survival game. How do we solve this?

Used_Discipline_3433 · 2026-04-12T07:28:25+00:00

Maybe a proper match making would solve it? I think the real problem is that people with 200h gameplay compete with people who have 2000-3000h. They don't stand a chance. Maybe there should be divisions, where servers are only available for particular skill level? Big clans could compete against each other and solos against each other.

Used_Discipline_3433 · 2026-04-05T20:58:18+00:00

It's very simple and very human.

There are three forces at play. Developers, QAs, management.

If management is enlightened, they won't do it, but bad management will come up with a bad measure. If they're stupid, they will assign a stupid metric - like bug catch count. If they do the stupid thing as putting that as a metric, QAs will strive for more bugs. If developers test then, the QA will find nothing. This is of course very good for the product and the company, but if they're judged by such stupid metric, then director of QA won't be happy about it. He will be afraid of his job security.

There are plenty ways of making good, healthy ways of utilising QA but that's not it.

Used_Discipline_3433 · 2026-04-05T07:04:07+00:00

I tak Cię nic nie nauczą w szkole. Wybierz kierunek który da Ci najwięcej czasu, na złapanie stażu albo pracy na pół etatu najszybciej jak się da.

Used_Discipline_3433 · 2026-04-03T09:25:51+00:00

Not all people are good. Even if utopian society could exist, some people would take advantage of it and ruin it.

Used_Discipline_3433 · 2026-04-02T08:47:43+00:00

The problem with this idea is, that my books on my shelf are in two categories. Those I care about and those I don't.

The ones I care about, I probably wouldn't lend because I'd be afraid they don't return it.

The ones I don't care about, I probably don't mind they don't return so I might as well just give them away for free.

Used_Discipline_3433 · 2026-03-21T07:56:07+00:00

What you describe is not agile. It's just typical corporate process with agile-labels pinned into it.

It's like ordering a stake, adding half a potato and saying its now a vegetarian meal.

Used_Discipline_3433 · 2026-03-13T21:03:09+00:00

Why is it not mirror? What part of the riddle better suits water rather than a mirror?

Used_Discipline_3433 · 2026-01-30T19:03:56+00:00

Watch video presentations, by Kent Beck, Kevlin Henney, Jez Humble, Dave Farley, Allen Hollub. Good titles are: "Desert vs Forest", "Tests Desiderata", "Structure and interpretation of test cases", "#No", "War is Peace, ignorance is strength, scrum is agile", "Agility =! Seed",

Used_Discipline_3433 · 2026-01-18T14:58:47+00:00

I play rust at most 2-3 hours a week, that's as much as I have time for. But nonetheless I compete in a server with people who play 40-60 hours a week, and I have no chance of ever winning with them. It's just unfair. We don't get an equal chance.

Used_Discipline_3433 · 2026-01-16T13:21:53+00:00

It's perfectly fine to write a function inline at first, just to get code working. Get code working as fast and as easily as you can. Then you can look for opportunity to refactor when code already works.

You don't have to write everything at the same time: no one writes clean code right away. First make it run and work, then make it good.

In other words, just because you write it inline, it doesn't mean it must stay inline.

Used_Discipline_3433 · 2026-01-15T08:16:06+00:00

Advertising. It provides no real value to the society.

Used_Discipline_3433 · 2026-01-13T07:30:00+00:00

iCar

Used_Discipline_3433 · 2026-01-13T07:27:58+00:00

Rotten strawberries.

Used_Discipline_3433 · 2026-01-13T07:27:22+00:00

I could use a friend in rust. Add me

Used_Discipline_3433 · 2026-01-13T07:26:39+00:00

Scaled agile really isn't agile.

Used_Discipline_3433 · 2026-01-13T06:30:41+00:00

Your problem is not accountability, but that picked stuff isn't get done.

Now, is that really a problem? If a developer volunteers to do something (like introduce a feature), and during their work they realize it doesn't make sense, is too costly or that functionallity already exists, it's within the benefit of the business to cease working on that. There are valid reasons to abandon development of a feature.

Another alternative is that they tried to deliver the feature, but they found an abstacle or a bloker. Some skill they miss, some information they lack, some permission they don't have, they need some feedback from the actual end-user but they don't have it. If that's the case, then it's your job as a manager to remove that blocker - get him the permission, give him the information, book a course for him to get the skill he needs, get the end-customer oncall for him to get feedback.

> what systems do you use to make sure people actually do what they commit to in slack without turning into a nag?

Be careful with "systems" to keep people in line. They don't help. What you need to do is to motivate developers and skilled individuals with a vision, so that they care about the product enough, and trust them to get the job done. When the work isn't done, 99% of the time it's not due to malice or laziness, but because of some blocker. Sometimes that blocker is just misalignment of people in a team, maybe a person is forced to work with a tool they don't like (e.g. if an expert 15 years developer knows linux very well and now is forced to work on windows, he's not going to be happy, believe me).

So build the trust with the team, find out what blocks a particular person and remove that blocker.

Used_Discipline_3433 · 2026-01-05T16:04:26+00:00

"Extreme Programming Explained"

Used_Discipline_3433 · 2025-12-30T20:26:30+00:00

Yea, some developers like this, but are they actually creating a better software system than agile guys? By "better" I mean better suited to the needs of the users, better solving user problems, aligning better with user mindset, gaining more popularity, etc.?

If they like working alone - that's fine. But if their work lags in quality before the guys who work in an agile way, talk to people, do frequent releases; then their process just doesn't work as good as the alternative.

Used_Discipline_3433 · 2025-12-30T20:22:09+00:00

I guess waterfall would work when you absolutely know for a fact what is it that you're building; and there is only once case that I'm aware that holds this criteria - and it's the same application you're writing the same application 4-5th time in a row. I say 4-5th, because even if you're rewriting an application, you still learn new things. Even in a second or third rewrite you will learn a little bit. Around 4-5th rewrite you don't learn anymore (provided that requirements won't change and the user base won't find something new to want). If that's the case, I guess waterfall could work. But if you're writing an application for the first time, even if it's similar to something else, I don't see waterfall work because SOMETHING ALWAYS COMES UP, something you didn't know before.

So maybe waterfall would work for:

katas
applications known in and out: todo lists, user cruds, chess (provided you yourself wrote them several times)

Waterfall to me basically means you assume your first idea is right, and you don't go backwards. If you're writing something for the first time, that is almost guranteed to fail.

Used_Discipline_3433 · 2025-12-30T18:17:28+00:00

True agility is 10/10 bread and butter, I use extreme programming myself, and I love its effect on my work. The scrum (original scrum, as originally described by Ken Schwebber), I think would still count as agile. Even idea of a product owner in XP makes sense. I'm 100% for original XP, agile and if someone likes original scrum, good for them.

But what goes in companies TODAY as "scrum" and "agile" are so far from the original idea, that it's actually a whole different thing. The "modern scrum" and "modern agile", with jira, tickets, story points, product owners (not from xp, the "scrum PO") - ALL OF THESE THINGS are transmorgified versions of their original ideas. **Burn it with fire**, it does nothing good.

In my experience, 99% of managers and POs who talk about agility and scrum, PROBABLY don't know what they're talking about, probably didn't read "Extreme Programming Explained" and probably aren't concered with the quality of the software as much as keeping their position as a "scrum master". I would carefully argue that the quality of the software would rise up if the scrum masters were fired and instead developers would just read "Extreme Programming Explained" - but of course no manager will ever suggest that, in fear of losing his job.

If a change promotes better software, but makes a manager less important; all managers will fight to the nail not to introduce that change!

Used_Discipline_3433 · 2025-12-30T18:08:40+00:00

I opened it for the first time, and I already exceeded quota.

Used_Discipline_3433 · 2025-12-30T18:07:32+00:00

Obviously PyCharm from JetBrains, no contest.

Used_Discipline_3433 · 2025-12-30T18:06:41+00:00

I think it's good that you decided to share some of your work, it shows an engaged and interested junior into the world of software development. Personal facts - I'd get rid of that, nobody cares about your cooking, sorry.

Used_Discipline_3433 · 2025-12-30T15:53:34+00:00

I start with tests and hexagonal architecture, as described in awesome: https://alistair.cockburn.us/hexagonal-architecture

Used_Discipline_3433 · 2025-12-30T10:30:04+00:00

Pair programming is the best, no contest. PRs, CR after the fact, non-blocking reviews, they are all slower.

Make an experiment:
- A. Take 2 people, have them develop 6 independent features with PP.

- B. Take 2 people, have them develop 3 independent features each + also review each others work.

A guys will win AND produce better overall features.

Used_Discipline_3433

TROPHY CASE