[lmarcos]

And here it lays the paradox. All the tools you have mentioned have little to do with programming (one individual solving problems by writing code). The tools you mentioned have to do with software engineering (a bunch of individuals solving problems by writing code, plus a bunch of constraints).

The joy is in programming, not in software engineering. At least that's how I interprete the GitHub comment (and all these stories about developers that cannot take it any more and burn out).

[genidoi]

I think it's easy to forget that modern tooling (+AWS/GCP/Azure) let's one dev match or exceed the productivity of 15 developers and a couple of PMs in 2005.

[mattmanser]

It's a laughable claim to say one developer has replaced 15, and obviously not true. The vast majority of code was business logic and still is.

Today's 'process' is no more efficient than, say, deploying rails to heroku in 2007. And even before that, you'd spend half a day writing an automatic deployment script, and then deployments would take a couple of clicks and you'd never think about it again.

[SahAssar]

I'm not sure if you think all devs 15 years ago where stupid or all devs today are awesome, but either way I'd say you're wrong.

[adamnemecek]

He means that tools have improved.

[SahAssar]

If tooling means a 15+x improvement then it seems like it is one or the other.

[SQueeeeeL]

That's a very specific meaning, like in terms of scaling maybe? But in terms of actually meaningful problems solved for end users... But there very nature large scale systems aren't very common, but everyone is chasing that unicorn startup which can serve 10 million users; so scalable APIs are more "practical" then simple workflows

[phkahler]

Scalability seems overhyped. If you write small efficient systems they can handle a lot of work. If you use big clunky frameworks that convert simple things into map-reduce style problems of course you're going to care about scalability and how much your AWS bill is going to be.

[ditonal]

I could not agree more.

In many technical interviews, they want to talk about "scalability", using fancy big data software for horizontal scalability etc

But I also know from experience that many, many of these problems would be more elegantly solved by more traditional tools like Postgres, especially since servers have gotten more powerful, the cloud service options more plentiful and reliable, and the software more optimized. The "scalable" approach can lead to massive amounts of wasted person hours unless you're sure you really need it. But if you say, "just use RDS or CloudSQL, or maybe BigQuery", you get perceived as a newb by the 24 year old who just got his MS doing Spark work on toy problems.

[oalae5niMiel7qu]

I spent all day today and Friday just trying to get a Google Cloud Composer project to run locally. I'm still waiting for that increased productivity that modern tooling supposedly grants me.

[blueterminal]

I don't need to worry about many many trivial things I had to worry about before these tools, and now I can actually work on the problem I'm trying to solve almost immediately.

[vbezhenar]

For some people solving business problems is boring. But tinkering with those things that you're calling trivial is what brings joy.

[pdimitar]

You and me both.

[sdevonoes]

Is that true tho? I mean, I love programming, but I hate React. I love thinking about data structures and their relationships, but I don't like Docker. I spent hours thinking about how can I solve a problem (just for fun) and I absolutely don't need GCP nor Azure. I like coming up with cool algorithms (or reading about them) but I find Laravel (or Django) really unelegant and not worth my time.

[ativzzz]

It depends on the problem you're solving of course. All of these tools are built to be able to solve larger, more complex problems more effectively. You are still welcome to ignore all of them and write a cool program for yourself for fun, just don't expect to get paid for it.

Ultimately, we get paid to solve business problems, not to have fun with programming.

[stevedonovan]

This is of course true. But is a particular fashionable technology the best way to solve that business problem, or is yet another layer of fun? I suspect that being able to deliver simple scalable solutions without bandwagon dependencies is going to be a differentiator, in _business terms_