Hacker News Reader

Comment by fractionalhare | Hacker News Reader

A lot of what you describe is attributable to resume-driven development, in my opinion. Complex solutions are used to insinuate that the engineers who implemented them are solving complex problems. This in turn improves their marketability by insinuating they've got the razzle dazzle and trendiness under their belt that justifies $500k a year.

Sometimes it's also not resume-driven development, at least not intentionally. Sometimes it's because the engineers just want to work on overcomplicated shit. For example I have my personal blog running on half a dozen AWS features - S3, Athena, Cloudfront, Cloudwatch, Lambda, SNS, SES, ...

I don't need any of that for a simple blog, and I write on it like once a year. And the site is still slow as shit (relatively) even though it's static because I haven't optimized the font and script loads to be non-blocking. But it was fun to set up!

View on HN

What you describe you did with your blog is, in some sense, resume-driven development: you probably learned stuff in the process, which might be useful in a future job situation.

The difference is that nobody paid you for doing all that unnecessary stuff. Doing unnecessary things for learning is good, but not what a company is paying you for, usually.

If the resume isn't what drove them, then it isn't resume-driven.

There is also an element of each project optimizing to its own minimum. If each project selects the best language, tech stack, hosting stack, etc, for itself, it creates an overarching complexity across projects.

Fixing this requires lots of communication and leadership. Each project may need to select sub-optimal components (like language) for itself, but in doing so it can remove overall complexity.

I agree about the resume-driven development aspect, and I think it's great to use a personal project as an outlet for experimentation! Too many people do stuff like that at the expense of unnecessary complexity in production systems.

I'll grant that collectively an engineering team might decide to overengineer a simple, noncritical service to get production experience with a technology or two that they are targeting for future adoption. Nothing wrong with that, and there's nothing wrong with making room in the schedule for engineering experiments to test out new technologies.

Managers and the rest of the business, for their part, need to understand the need for experimentation so it can be done honestly and not under the guise of other work.

Folks with the outside perspective often attribute some intent to a situation, but if they went through it, it would be obvious and simple.

I think engineers try to do the best they can. It's just old guys might do it the mainframe way, slightly younger unix, then windows, then linux.

Or folks who've been with the culture do it that way, and new folks from outside the company bring new college grad or last-company-i-worked-for culture along with them.

And folks who try something new suffer from the 'fog of war' and your "the docker solution" that got everything started so well makes you a real expert in nested docker configurations and firewall issues. :)

Reply on news.ycombinator.com