Yeah. I feel a lot like this too. I left my most recent job in May and don’t have plans to return to tech anytime soon. To fill my time and to try to do something actually useful, I decided to start writing about learning more and thinking better.
On the surface, this sounds like a great idea. The problem is that, once you look at the details, you realize there are none.
How is this going to work? Where does that $68bn get re-allocated? Who will benefit from this? What is the economic advantage of investing in transit infrastructure in dollars and cents?
I've seen a few of these proposals that sell hopes and dreams with no discussion of how it's going to work. Until I see that, I can't support this.
Can you clarify what you mean by "transit oriented development"? As a general rule of thumb, 10-20 story tall buildings are an eye sore. I don't think it makes sense to make things denser if it's going to be so ugly that no one wants to live there.
I think it's a stretch to say that the peninsula will remain majority single family home cities. Everywhere I look all I see are new apartment complexes being built.
Well, it depends. I personally don't feel the need to self-promote to get a raise. I'll probably lose out on a few raises or promotions because of that, but I make a good amount of money and I'm good at what I do. That's enough for me.
Absolutely! Unfortunately, this is very hard to sell to teammates on the SPA bandwagon and management who require all developers to be buzzword-compliant.
Run `( find -E ./ -regex '.*\.jsx?' -print0 | xargs -0 cat ) | wc -l` inside your `node_modules/` folder. It counts lines of code in JS files. Prepare to be sad.
True. There's another thread in here somewhere talking about premature generalization. I think that's what you're getting at with "Do it too soon and you end up choosing the wrong boundaries".
> There's still a lot of work out there that really boils down to basic CRUD and reporting at the end of the day, and developers naturally begin to invent complexities on top of that CRUD to make the work interesting and challenging.
I'd go so far as to say that _most_ work today (at least in startups) is building CRUD apps. The technology has changed, but the work hasn't. Inside of building CRUD apps in Rails, we now build them in React.
Building a website doesn't have to be complicated. You build a Rails site 10 years ago. You probably used jQuery, if you used JavaScript at all. Why can't you do the same today?
The real problem here is that not enough developers understand that "just because you can, doesn't mean you should." Once more of us get a handle on that, life will be better.
The day I learned about premature generalization is that day my speed as a developer jumped by a factor of three. When you're generalizing, it's easy to overlook how much time that takes.
My rule these days is that, in most cases, I shouldn't generalize before the same code exists in three places. Why not two? In my experience, things that are done twice aren't necessarily done three times. But things that are done three times are likely to be done a fourth.
I'd change this to "Write as little code as necessary, but no less." The problem with "Less code is better" is that some folks use that as justification to write clever one-liners that are difficult for other developers to read. That is not better.
That aside, I agree with everything else you said!
Ego is one of the larger problems I've seen over the years. This usually shows, as you mention, with someone trying to sound smart. The irony here is that I've consistently found -- both inside and outside the software industry -- that the smartest people in the room are the ones who can speak about complex topics in a simple way.