This unfortunate obsession with new and shiny in the Valley is why we have to learn lessons like the benefits of relational databases over and over. Most of the new stuff isn't improved, it is simply different.

I've now used several relational databases, Cassandra, couchbase, and dynamoDB and here's what I've learned: They all suck. Every one of them in their own special snowflake ways, but they all suck.

That's what differentiates good engineers from great engineers: they know what to avoid and when to avoid it.

few days ago had a guy tell me that "relational dbs are dying because google only uses non-relational dbs"

Relational dbs sure, but there are legitimate scale reasons to use a distributed key value store (for instance). There is no reason to be stuck with PHP today though. It's a very backward language when you compare to something with a modern type system/features (e.g. Go, Rust, Clojure, Java 8+, Scala...). Devs need to have a passion for learning technology. Not because it's the shiny new thing but because the new tech often _does_ offer benefit.

Often times you have no control over the technology stack you use because other factors drive your choices. I'm stuck developing in PHP because the tool we are using is written in PHP.

You often have to learn this stuff outside of your regular job. Once you know another stack then you can find another job using it. That's how you exert control over your career. Tying yourself to one company (or stack) is a slow death sentence.

EDIT: to those downvoting this... Do you disagree with me (i.e. you think it's a good career decision to stick with a single tech stack) or do you agree but dislike that it has to be this way? Genuinely curious because I didn't think what I said was controversial at all, just industry observation/common sense.

I live and work outside the valley, and I know python and Java, dabbled in scala, rust and lately C# -- no one out here will give me a job on any of those languages because I have no professional experience with them, and some of them no one here is using yet

You're being downvoted because you are arguing the details and have missed the wider point being made.

Have you looked at modern PHP though? I haven't looked extensively, and I'm not very familiar with type systems in general, but PHP 7 just might qualify as a modern type system (albeit optional) and since about 5.5 it's had pretty modern features like closures and traits. There's also hack-lang (Facebook's extended PHP.)

I have not and you're probably correct that it's not as bad as it used to be. That being said, this looks like a great case for learning new technologies/languages since the language you do know may change out from under you eventually anyway. For instance if a real type system shows up in PHP, prior experience with Haskell or Rust would allow a PHP developer to take advantage of it.

tl;dr: always be learning.

Here here, that's me. Not going away any time soon. It's not exactly sexy but it pays the bills and there's plenty of demand.

I didn't even know PHP before I started on this journey at the beginning of the year. I was trying to peddle my (admittedly meager) Python skills but everyone who had money to pay wanted boring PHP devs to maintain and build on 7-10 year old systems, so I brushed up and landed a few nice stable gigs. Will easily clear 6 figures within the next month or so for the year.

I've been thinking of specializing in maintenance of super boring old systems. I was wondering Is there much of a higher end market for it(100-200/hr)? And did you find one client for full time or a bunch of smaller gigs at 5-10 hours a week?

I have one main client that will basically pay me hourly as much as I'm willing to work for them, but then I also try to take at least 2-3 other clients on each month just for diversity. The smaller clients I typically charge by project rather than by hour, and so far I've been able to get my rate on those after the project is done in the lows 100s/hour range. For me personally I don't know that I could get my schedule completely full of work like that, but it might be possible I suppose.

It's not a potshot at the technology, but the market itself.

I'm glad you're making that, but in Portland they are paying $15 an hour for PHP/MySQL/Jquery developers all day long. It's an over saturated market that peaked 10 years ago. Sure there are a few edge cases here and there but the majority of it is a swampy wordpress ghetto.

Folks who started on that stack in the 2000s (like me) and refuse to move forward aren't making 6 figures around here.

I think you're missing the point when you say that people working in the PHP dev space "refuse to move foreward." Other people above have made the point that there is PHP 7. PHP is now a modern language with namespaces. It's strange to me when I hear people commenting about PHP as if it's 1998 (or even 2008) or something.

Some people enjoy developing in PHP now. And there's plenty of work there, let me tell you. And all of it that I've seen pays a lot more than chump change.

It is relevant to the discussion because that's not a fresh skill set. Anyone not moving on from those technologies at this point should be concerned about their future in the industry. Maybe they can find jobs now, but without learning something new they won't in the future.

Tell that to all the COBOL programmers making serious money.

COBOL is tied to specialized hardware that's hard to move away from due to massive capital investment. PHP will run anywhere better languages run. And really, COBOL will be gone someday. If your career is on the line, it pays to stay current.

COBOL itself isn't tied to any specialized hardware, and you can get COBOL compilers (whether proprietary or open source) for all major platforms. If it runs PHP, it probably can run COBOL too.

The real problem with porting most COBOL code is that few COBOL applications are actually pure COBOL, they are full of calls to proprietary middleware, databases and operating systems. For example, a lot of COBOL code runs on IBM mainframes and calls mainframe packages like CICS and IMS and the underlying mainframe OS (z/OS aka MVS). While there are replatforming solutions which emulate some of these mainframe software packages on other platforms, the emulation is generally imperfect hence there is still effort and risk in migrating.

I think the biggest problem with mainframe COBOL software is not the hardware but finding people with the right skills to maintain it. Even if you use some replatforming solution to port it to a more mainstream platform (Linux/Unix/Windows), you will still need COBOL programmers familiar with the relevant mainframe technologies, plus they'll need to understand the limitations of the replatforming solution you chose.

The issue is not the capital investment on hardware. You can get an equally powerful modern server to replace your old AS/400 machine for a few thousand dollars. The issue is the risk to move away from that is not worth it.

The potshot was aimed at Winforms, actually, not SQL.

The sentiment often echoed on HN usually includes relational DBs that aren't postgres, but you are right, he didn't explicitly call out SQL, I included it because that's the usual skillset the devs I was talking about have

Oh, the geek pecking order is fractal and recursive on every scale, to be sure.