How could one change "rules of capitalism"? Capitalism is an idea, if anything's changed it was the system, so the system might have adopted some other ideas - that would be a change.
It's like having a car, disassemble wheels and call all cars useless.
It seems like USA is surprised that concentrating more and more power in few hands leads to corruption and as a cure they want to concentrate more power into hands of few (government) in the name of social justice expecting different outcome than before.
I cannot agree on your last point: capitalism is a system where those two (government and private enterprise) are separated by design, simply because first one has little power over second (free market) and second has little power over first (no interest in corrupting officials if there is nothing or little to gain).
> Do you think governments have had "more and more power" in the last fifty years? What is your reasoning?
If opposite was true then there would be never debate about helping bankers after crisis few years back, government shouldn't have power to "help" private investors with taxpayers' money.
> If you concentrate more and more wealth in fewer hands, then you can also expect corruption.
Why should I care about corruption inside companies? Corrupted companies are less effective, they will eventually die. What I care about is corruption inside government - you have no solution for corrupted officials - I have: just don't give them too much power, then even if they are corrupted they won't make much damage.
> The thing about capitalism is that capital generates capital. Someone who is already wealthy can "chill" and get a better outcome than someone who works much harder.
That's not the feature of capitalism, that's feature of corrupted government with too much power - in free market, if you have capital and don't create any goods, but only spend it eventually you have less capital - it's simple math.
Blaming capitalism for corruption while giving government more and more power, solution: let's give the government more power in the name of social justice and expect that no one in the system is corrupted - wow, that's just perfect reasoning...
Socialism never worked in the past, because it simply ignores the fact that people have no reason to work hard when they see someone who's chilling gets the same outcome.
Maybe losing valuable people is not affecting company straight away, but it surely affect the project. And with few project failing miserably (as they will if you do corporate waterfall) something might change. If not, then the whole company might fail. Remember, companies compete with each other, it just takes more time for some to fail.
I think you are missing one thing: why do you allow managers to say how to develop software when you are hired to be an expert on that matter?
I know, I know, it is convenient to not to take responsibility and just complain, but that would be so frustrating for me that I couldn't take it. And, yes, in my experience I saw many times where people who are not experts say how something should be done, for example they say "refactor is not needed" or "tests are too expensive". In that case I ask them one simple question: "how many contributions to the codebase you made last month?" The answer is usually silence. If they still oppose I just quit the job and watch the project fail from my colleagues' reports.
Simple as that.
In my professional experience as developer I'm terribly disappointed with so called "scrum masters" dedicated for the job, the teams that I worked in that implemented scrum correctly were the teams where the team itself took the responsibility to do it right on themselves.
...and we come back to one of agile principles: "the best architectures, requirements, and designs emerge from self-organizing teams". I think the scrum itself says to not confuse the job title with the role and I believe that's what happening in many cases. But it all looks good on paper, we have scrum because we hired scrum master so management is happy whereas in reality it is not true - I saw it many times.
The only thing that worked for me when fighting managers as such was to expose where they are wrong about scrum and/or agile. Foursquare, boldly, without emotions. Speak up guys, you are paid to be experts, share your expertise with the org.
What are you talking about is problem that you are committing to to much in sprint, thus, your velocity is inaccurate. If I can give you a piece of advice: not finished items should be marked as 0 work done and moved to next sprint, and thus it will affect your team's velocity in future sprints making you commit to less items, which should result in that eventually you will have real velocity of the team and you will know how much work you can complete in each iteration. Of course opposite is also true - with time you can get knowledge or improve codebase in such way that your velocity will go up.
I'm surprised, I've never had problems with org pressure, it was easy for me: either we do agile and you trust our judgement or I quit, because I know that this project will fail and I'm not interested in contributing to projects that are doomed to fail. Do you think I was unemployed for long in the second case?
I know what you are talking about, but those are the things I would never agree upon. This is against scrum, against agile. Where I can agree that scrum is not always the way, I truly believe agile is how software development should be done, so I can't even count how many of conversations about it I had with all those managers. Outcomes were two: they agreed to change and project was successful in most of the cases or I quit and project failed in most of the cases, so my experience is only strengthening my views over time.
Well, scrum literally says that the team should have skills needed to get the job done, so you can still defend scrum, whereas agile says about putting people's interactions over processes and about pursuing technical excellence, so creating tech debt is still not agile.
So, I'm not sure if we can agree on that, but, arguably, I believe it is not scrum or agile that are failing, but management who doesn't want to be agile or/and follow scrum. This is my experience numerous talk I had on escalated level when my team was rising issues with management.
One of the first things Scrum says is that you need to have a team with skills that ensures the job done. Same with Agile: literally says about "motivated individuals" and "self-organizing teams". So, arguably, you are not talking about Scrum nor Agile in those failing projects - you just share this naive view I saw in some managers: "we just put scrum master here and thus we have scrum implemented".
Exactly. I saw employees who said they have Agile implemented, but for example they were too weak to speak up, take responsibility and pursuit technical excellence. Same with managers: they say they are Agile, but trusting your employees that they will get the job done was a joke to them.
Just like there are companies who say they are Agile, but they are not, there are teams who think they have Scrum, but it is not Scrum. If you say that Scrum encourages tech debt and you had no autonomy then probably it wasn't Scrum.
The other option is that you were using Scrum where it doesn't fit.
By Pareto principle: 80% of times when I see "The tool X sucks" it is because people are using wrong tool or they are using tool wrong.
To make things even worse I also recently (v. 9.11.0) found Postman process hanging on in my memory after I close it. This behavior isn't bad on its own, the problem is that after few days (of not using the app at all) it ended up eating 10% of my CPU time.
Since killing the process manually after using the app isn't the experience I want to have when dealing with simple tool I ended up testing some alternatives.
I agree, on what you working and with whom you are working is far more important. I would even argue, that for a experienced software developer getting fluent with new technology is quite fast while getting to the bottom of domain in which your project will exist might take years, especially when you take into consideration that technologies share quite decent amount of concepts between each other.
Besides, in era of containers/WASM/open source developers never been more free to mix as many technologies in one project as they want or even switch them completely at any point of lifetime of a project.
There are also other reasons: using different tools with slightly different philosophy gives you broader perspective in general and also keeps you away from burnout.
You basically said is equivalent to statement that computer software is just a bunch of ones and zeros and everyone has access to ones and zeros for free. But at some point it stops being just chain of ones and zeros and becomes meaningful computer program. It's similar problem like with forbidden numbers - at some point how things are arranged overcomes the value of elements itself, but the line there is blurry. So yeah, the "naive statement" is still on your side.
That's somehow naive statement. There is a difference between getting full information just with one query and building complicated fail-prune system for weeks/months to analyze data.
Yeah, I would like to see them to, especially when I see something like this:
> When we benchmarked JDK 15, we saw that Java 15 was 11.24% faster than Java 11. Now, the gain of Java 17 over Java 11 is less. Does that mean that Java 17 is slower than Java 15?
> Well, no. Java 17 is faster than Java 15 too. Those previous benchmarks were run on a different codebase (OptaPlanner 7.44 instead of 8.10). Don’t compare apples and oranges.
Author is defending their other article by discrediting their own methods - what those percent values even mean if they differ so much between different versions of the same benchmark? Shouldn't benchmarks be profiled for specific workload types to simulate real life examples? How could you possibly change the workload so much it affects result so significantly and not change the nature of your benchmark?
I meet many women who could easily move into sex-work, but they don't, they have tiring job which pays pennies, but they know that in the end this hard working is much better choice. Let's stop playing on victim note, almost everybody has a choice and in case of OF it is always a choice.
I agree, trafficking is marginal problem nowadays, except maybe children trafficking, but this is totally different story. Prostitution today is a choice and, in developed countries, does not even have that much social stigma.
> I gained respect for OnlyFans as a platform because it enabled people to move from dangerous, risky work to relatively safe work
What about not getting into this and, thus, not being exposed to any risks? Sex-work nowadays is the matter of choice, it's not how it used to be in pre-internet era.
This is just shitty company strategy or corpo/wanna-be-corpo bullshit, I think you can find smaller companies where poor performance is harder to hide, thus they can't afford it and everyone's happy (except people who actually benefit from that bullshit, but they are not there because they were already fired).
I've never really understood the "architect" role, maybe because I've always stumbled across poor architects, but I generally don't agree it is a good practice for someone to make decisions (architecture) and not deal with consequences (actually code within this architecture). Those decisions should be left for team to make and, yes, opinion of more experienced devs should be weighted more, but everyone should have a right to speak.
Something that connects with above statement: most architects are involved only at the beginning, which is so unimaginably stupid considering the fundamental truth about software development which is: "requirements will change".
Personally, if I hear from recruiter that they havea an architect in team I always say "thank you, but no thank you".
From my experience, I can say there are 3 types of managers:
- with little or no programming knowledge
- with moderate programming knowledge (they used to be developers long time ago)
- with excellent programming knowledge (they recently switched to management or they still develop)
...and it is really PITA to work with that group in the middle - they assume they know some technical stuff (but they don't or it is highly outdated), they underestimate complexity and they are always relating to the times when they used to write code with that passive aggressive narrative like he thinks he would do better.
Obviously I've made some generalization here, I bet there are exceptions.
It is pleasure to work with the first and the last group because the first one needs to trust development team and the last one just does.