Live data from Hacker News

Ask HN: Have we screwed ourselves as software engineers?

news.ycombinator.com

251–260 of 430 posts

Re: Ask HN: Have we screwed ourselves as software engineers?

#251

The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work. Of course, there are plenty of project where judgement Is t…

I call it Resume Driven Development

Yes, this has been my observation as well. I also see this happening concurrently with what I call the "shiny object" problem. Developers have their eye on a shiny new library, framework, language, etc. and have a seated desire to use it at the expense of it being an inappropriate choice for the company.

I believe these two phenomenons are producing a positive feedback loop in the industry. Selected technologies address one challenge, but introduce complexity. The complexity becomes difficult to manage. So other technologies are incorporated to manage the complexity. In the midst of all this, core technologies are replaced, swapped out, or transitioned to under the desires of the dev(s). For example, switching from one js rendering library to another, while preserving the old legacy code. The complexity footprint keeps growing and it doesn't stop because the engineers themselves aren't entirely committed to the project. They can incorporate the new technology to the project, pad their resume, and bail to a new employer if things grow out of wack.

Re: Ask HN: Have we screwed ourselves as software engineers?

#252
post #210

I agree with the general sentiment, but I would add that Go is a very simple language. It's probably the simplest language I have ever used (besides C).

A very simple language with low expressiveness leads to very big bloated codebase.

k8s is an excellent example.

Re: Ask HN: Have we screwed ourselves as software engineers?

#253

Earlier quoted context omitted.

I see everybody around me moving to cloud, without really good explanation why. People just buy into the "cloud" marketing. They don't have the ability to think and reason, and so don't understand that "cloud" just means "renting someone else's computer." I built a complex in-house medical system. Quick, reliable, and liked by the users. I was in the middle of adding a major new feature when all of the management in…

Given what you explained, it seems to me that the cloud was an excuse given by the new overlords to just get you out off the way. Cloud is fashionable now, but any excuse would work for them. This seems to be a power grab.

I don't think it's about power. Because of the way the organization is structured, I am isolated from the IT department.

Moving me out brings no advantages to either part of the org. In fact, it's probably a disadvantage to IT because it has to burn three people from its allocated headcount. Where previously, it had a bonus person that didn't come out of the IT budget.

Re: Ask HN: Have we screwed ourselves as software engineers?

#254

Earlier quoted context omitted.

With extensive experience in this vertical, (marketing agency and analytics), 200GB is a _partial_ day for one datasource, let alone table or total DB size.

but does team have 1 IT/ data person? Edit: sorry I see that you are the same person I was replying to. Then to understand it better, who is consumer of so vast amount of data?

The company has 1 IT person and uses a third-party vendor for IT support. We have several data engineers and scientists, but we are not specialists as DBA or cloud infrastructure; it's just one very small part of our work.

Re: Ask HN: Have we screwed ourselves as software engineers?

#255
agree, some folks just redo things because "I can do it a different way", that might be over-simplified the situation, but essentially it is for these folks. the reasons could be different, resume, personal preferences/skills, even could be work politics ...

Re: Ask HN: Have we screwed ourselves as software engineers?

#256
post #12

> Rust for CRUD apps? Are all CRUD API’s insensitive to performance? Correctness?

No, but Rust is a low productivity, high formality language; one needs to make a tradeoff whether it's really that important. Given that most CRUD services are just a layer on top of a database. This is the reality of software development; you have a budget and you have a goal. If all your budget goes up on making it correct without finishing it, you have a problem. Anyway, it's just a CRUD app, it doesn't have to be…

I'm far from being proficient in rust but my productivity writing crud apps in it is pretty good (just throw some Rocket + SQLX and you're flying).

Rust is a very high level language, it's not like writing assembly. You rarely run into complicated situations with the borrow checker when writing trivial crud apps.

The ecosystem is not as mature for web apps compared to other languages, so it may be more efficient to pick something else, but ultimately the most important factor (when building trivial stuff) is picking a language you and your team are comfortable with. Whether that's Rust or node.js, it won't matter much.

If I were to make something else which is better supported in Rust, eg. a videogame, using bevy + ecs would run circles around a bunch of other languages and their game frameworks.

Re: Ask HN: Have we screwed ourselves as software engineers?

#257

Yes, but not in the way you describe. Software engineers have power right now, we should be unionizing (even if the union is only pushing for things like IP clauses and non competes to be less draconic). Build the union while we are strong so it's there when we are weaker. A union doesn't have to be a huge monstrosity. It can be simple and fight for a few basic standards in the industry.

Everyone just needs to send me $1,000 a month in dues and i'll start sending google and amazon some very strongly worded emails on our behalf.

Re: Ask HN: Have we screwed ourselves as software engineers?

#258
post #150

Earlier quoted context omitted.

OOP to me would be classified as the industry blindly moving towards unnecessary complexity. It is indeed the definitive example of how the industry over-engineers things. While still prevalent today, there's a huge sentiment against this paradigm. Modern languages and frameworks such as React, Golang and Rust show how the tide is turning against this.

Three object oriented languages prove how there's sentiment against OOP? Or are you saying that Rust/Golang/React are simplistic in a world of over complexity. React I would generally agree with, the other two not really.

All three are moving away from OOP.

Functional components in react. Zero classes in golang or Rust.

It's actually quite an obvious paradigm shift. No classes with these languages yet every language prior to this has classes.

Yet I don't understand why people still insist on calling go and rust object oriented or why they try to argue this point when there is such an obvious change. I mean sure you can twist the language into something that looks like it's oop but come on man. Haskell is OOP if that's the case. Let's not argue about whether these languages are OOP or not. The point is there is an obvious movement AWAY from OOP with substraction of popular and critical syntax and features.

For React , the trends are harder to see. See here: https://hackernoon.com/react-functional-components-are-the-f...

The react team recommends functional components over classes, and react itself was derived from functional languages and concepts. I believe the team ideally would like to see ReasonML as the future and react with js syntax is more of a necessary in evolutionary inbetweener thing.

Re: Ask HN: Have we screwed ourselves as software engineers?

#259
post #157

Software Engineers are generally intelligent people. Intelligent animals need stimulation or they get bored and depressed. I think collectively, "let's move to Rust" is at least partially because we're not challenged enough by writing the same CRUD app for the 20th time in the same language we've been using for the last 5-10 years, and we want to leave our mark in a new ecosystem by implementing whatever is missing.…

To keep it fun someone probably has to do the boring work of making things backward compatible.
Post reply on HN