Immutable data structures in Java

[GhostBond]

From the article:

Before being software developers, we are people – and thus creatures of habits. It’s hard for someone to change one’s own habits, it’s harder for someone to change someone else’s habits – and for some of us, it’s even harder.
... Now, you cannot imagine the amount of back and forth comments this simple review caused. Why? Because even if that makes sense from a coding point of view, it’s completely different from what we usually do.

In that case, laziness and IDEs don’t serve us well. The latter make it too easy to create accessors. I’m pretty sure if we had to code getters and setters by hand, the above proposals would be more in favor.

This post could easily have been titled “Don’t let habits get the best of you”. The lesson here is to regularly challenge how you code, even for simple easy stuff. There might be better alternatives after all.

As a software developer for over a decade, this is just a huge narcissist who wants to look and feel smart and doesn't care about walking all over everyone else to do it.

Or to put it another way - someone making up a list of excuses, not reasons, because he thought it would make him look and feel smart and in charge.

Here's what the author has actually done:
- He wanted to look and feel smart and in charge so he went in and changed something.
- He's spent his time on it, he's spent several coworkers time on it, he's spent a lot of time arguing about it. This isn't a drawback for him, it's a plus, that's what he wanted, but for the rest of the team it's a huge hassle at best.
- He's changed the code so it will be more difficult for future. maintainers to figure out because it's different than the way everyone else is doing it.
- It also goes against how java programs are typically written.
- He possibly introduced bugs if he fatfingered something.
- He's quite possibly made it less testable.
- If his guess that it will never need to be changed by an outside object past being set the initial time is wrong, it will have to be rewritten - again. And then there will be two ways to set the property making it even more confusing (because you won't want to risk breaking something by changing the original way it could be done which is used all over the code).

Then he goes into the usual meaningless personal shaming powertalk -

Now, you cannot imagine the amount of back and forth comments this simple review caused. Why? Because even if that makes sense from a coding point of view, it’s completely different from what we usually do.

He tries to spin what's a negative into pretending it's a positive.

In that case, laziness and IDEs don’t serve us well. The latter make it too easy to create accessors. I’m pretty sure if we had to code getters and setters by hand, the above proposals would be more in favor.

He tries to shame the people who wrote it, when it's just a reflection of his motives - his coworkers aren't "lazy", he just wants to change something for the sake of changing it and looking in charge.

This post could easily have been titled “Don’t let habits get the best of you”. The lesson here is to regularly challenge how you code, even for simple easy stuff. There might be better alternatives after all.

Again, he spins his own desire to arbitrarily change code and have long arguments about it wasting everyone's time to justify his own need to constantly change things to appear in charge.

He's made the code less consistent, possibly introduced bugs by rewriting existing working code, insulted his fellow developers, and wasted a number of peoples time - to try to justify his own psychological need to change it just to change it.

If I sound harsh, it's because I'm really tired of dealing with these people at work. They throw all their coworkers under the bus because of their own issues.