Ask HN: Have we screwed ourselves as software engineers?
71–80 of 430 posts
Re: Ask HN: Have we screwed ourselves as software engineers?
#72Standup and fight. I am: https://htmx.org
Re: Ask HN: Have we screwed ourselves as software engineers?
#73Re: Ask HN: Have we screwed ourselves as software engineers?
#74Need container orchestration? K8s is the best on the planet far and away
Need accelerated compute? Rust is a fantastic language that saves us from c++
These tools are all fantastic and we should be very grateful we have them. If people are using them outside their use cases then that’s just bad engineering.
Re: Ask HN: Have we screwed ourselves as software engineers?
#75The 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 see everybody around me moving to cloud, without really good explanation why. Only reasonable thing I can see as an pattern is that cloud experience on top of data things gets paid 30% more. It made me consider cloud a lot.
I was considering switching to cloud, just so I can put in my CV "experience with migration to cloud".
For next person commenting that it makes sense: it doesn't with 200gb database and super predictable workload, growth and usage.
Re: Ask HN: Have we screwed ourselves as software engineers?
#76If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. I think you're just in a very negative space if you start with "Distributed systems" as something overly complicated. At some scale getting a bigger machine either doesn't make financial sen…
> But all those ideas solve real problems too. All of them, except for blockchain. That one can go die on the trash heap of history.
Re: Ask HN: Have we screwed ourselves as software engineers?
#77I think that as developers, we need to resist these trends and go with working stuff. But that's difficult, because for every developer that will go "Java is fine", there will be a dozen, usually younger developers, who are hyped up to use whatever is cool at this point in time. But this is where the senior developers and architects should come in; they need to make a firm stand. Make things like https://boringtechno…
Re: Ask HN: Have we screwed ourselves as software engineers?
#78Yes, 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.
The purpose of a union is to create a labor cartel which tends to standardize the price of labor above the rate at which the market would likely set it. IP clauses and non-competes are a small part of the issues plaguing our industry. Putting constraints on the labor supply is probably not a good thing; it leads to the market for labor relocating to less union-friendly climes. Ask anyone from Detroit how well that wo…
Apple and Google aren't going to just shut down in California because a union asked them to give some concessions that materially improve engineers lives.
Re: Ask HN: Have we screwed ourselves as software engineers?
#79Yes, but it has very little to do with any of the things you mentioned. Software became so prevalent that it became a mantra, "Software is eating the world" but people in IT have little to no choice in what's put on the plate. They've been convinced that positions of responsibility and authority are bad and should be left to the MBA's. Eschewed most industry groups that provide some semblance of protection that nearl…
> They've been convinced that positions of responsibility and authority are bad and should be left to the MBA's. Meh. From my experience, many developers actively don't want to go into management, because usually your whole day is filled with management crap and you can't go and actually code any more. And developers who do switch to management often end up as miserable bosses because their bosses don't care about "l…
These are clearly the wrong people to be pushing into management. Good management (it does exist) includes people who have coded, but are willing to give that up to enable others to do that. They get satisfaction from being enablers and making space for their underlings to be creative and make decisions.
Further, there are many excellent managers who don't have a typical developer background, but can recognize what success means for their team within an organization and how to achieve it. I've been managed by many excellent managers with backgrounds in chemical engineering and the classics.
The developers you describe should decline these positions and find a better fit where they can make better use of their time. Choosing to accept positions like this hurts them, as well as others.
Re: Ask HN: Have we screwed ourselves as software engineers?
#80> 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…
Setting aside performance (Python is slow as molasses) that still requires some qualification because there is the 'maintenance' dimension. I would take Rust over Python for CRUD any day, because the 'formality' is a feature not a bug for maintenance. I would take Java/C# over Rust because the former balance performance and formality very well. In fact, I wouldn't use a dynamically typed language like Python or Ruby for backend infrastructure code if there were any performance or long-term maintenance requirements.