Software developer thread
Thread for all the people who are working towards, have been, or are software developers.
Let me begin by saying that *magic* in ruby on rails, spring boot, and shit like that is all nice and dandy until you scale your project larger than a fucking hello world.
It blows my mind that enterprise is so balls deep on spring boot. Fucking cancer of a project. Don't get me wrong, abstractions are great. Abstractions aren't magic. Magic is when shit is not explicitly set anywhere and are done for you.
This might be shit like automatic wiring of routes based on function name. Or running a series of uninspectable SQL to map into objects. Or build HTML pages based on the regex of the model. Anything which is auto built without being explicitly set.
Don't even get me started on the fucking shit show that OOP is, with shit like spring boot, JPA, etc. Adding magic on top of that is like adding poisonous spiders to a cockroach pit that you live in.
Also, what the fuck is the fucking problem with people who write shit like
PersonIdNumberGenerator that takes a PersonIdNumberStrategy made by a PersonIdNumberStrategyFactory. Then the Generator makes a PersonIdNumberGenerator produces a PersonNumberId object which is just a fucking wrapper for an int. Of course everything is an interface but drilling down this fucking concrete strategy, you find that to motherfucking shit just produces sequential integers.
Software developers can be the fucking worst motherfuckers alive istg.
>>21008yeah I hate all the shit frameworks too. they're needlessly heavy, the bug treadmill for them is crazy with so many components many of which you may not even need to use but still keep up with.
but there is the whole hype train from everywhere that you can't avoid. normies telling you you can make his dream project with spring boot in a week, developers who love to follow trends, tech hypemen telling you it's the new hotness and you're old and busted if you don't jump on board.
really, it's never the tools themselves, it's how everybody tries to build a whole house of cards on top of them then it fails as usual. rails for example, still slow and shit and terrible at parallelization but everyone wanted to build everything in rails 15 years ago for """developer happiness"""", it was never about developer happiness it was because you get sold on it by the 5-minute blog or whatever it was tutorial.
I still find that these trends take hold more easily in commercial environments. like "ideas guys" and developers with groomed LinkedIn shit with the newest buzzwords. people who just like to make software, a lot of free software contributors use it when it will do the job but I rarely see mass trends taking hold so strongly there (there was the let's write everything in rust thing which thankfully has quitened down, I like rust a lot but everything doesn't need to be in it and I don't like that the rust toolchain is not GPL, unlike GCC)
>>21010job will only teach you how to get the job done.
it is in their interest to keep you as a replaceable cog and not someone with much freedom to do or learn new things.
learn on your own time, make some hooby projects.
>>21008the new (actually like 3 years old by now) hotness is spring boot "microservices" with a byzantine message queue tying them all together. giving rise to monstrosities like "orchestration" and "choreography" between the different services completely defeating the purpose of having independent services.
corporate development is a clown show that just bandwagons dumbass cargo-cult trends from the biggest companies. Amazon increased revenue by 4 million percent by abolishing piss breaks and using a message queue? surely we must also do this to succeed.
>>21022A lot of software shops opened up as rails shops. Bootstrap and rails were the fucking bread and butter for these companies. They delivered quickly, and well working products. Rails is great if you're building essentially disposable products like delivering these solutions to clients. Same with springboot. You essentially configure gems or spring libraries and they do everything else seemingly like magic. Spring is particularly good for delivering bigger products to clients.
They're not a good choice for maintainable software, or software that models a domain that's even a little complicated or non-standard, which is basically most use cases. They're also not good for teams that aren't specifically in a spring boot or rails company. There are a million pitfalls that can only be avoided by institutional knowledge. You can't depend on that one spring expert or ruby expert to be in your team forever.
>>21026>scale from hello world to IPOLmao lies.
>>21027https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
The wrong takeaway here is that monoliths are better than micro services, which is what they kind of imply by centering discussion on their move to a monolith. The takeaways are that cargo cult programming is fucking dumb, that poorly thought out microservices are fucking cancer, and misusing fancy tools just because it feels smart is actually really fucking dumb. As you said, it's a cargo-cult clown show imitating morons like these.
>>21030>The takeaways are that cargo cult programming is fucking dumbindeed.
and if this article came from anyone else other than Amazon or similarly large tech company, you'd have the usual hackernews suspects with job titles like "digital transformation ninja" writing countless counter-articles about how this is misguided and short-sighted and how they helped startup DeliveryBozo(tm) to "scale-up" from their monolithic mess. but now those same people will not dismiss it on reflex because they are cargo-culters who revere corps like Amazon.
>>21031Now that you mention it, I applied to DeliveryBozo but got rejected :P
I used to work at one of the Big 5 tech companies. Our team was developing microservices, but these mofos were micro. They of course wanted to scale these to millions of users worldwide so they thought that if each microservice handled one thing "in isolation", then that would be a silver bullet. Basically you had a microservice for each model. So if they'd design twitter, there'd be a "User" microservice, another for "user tweets", "user friends", "community belonging", etc. Each with their own user facing API. So each call to the API triggered a cascade of inter micro-service calls, which you had to be careful not to cause a cycle. The API latency could take at least half a second, with some taking nearly 2 seconds. The database we were using for each microservice was a document NoSQL/mongodb, which meant overhead was insane, indexing was a pain, no joins, deletes took ages, etc.
When I joined the team I was a junior, I didn't know shit. But after like a year of working on it, I told my boss that what we were doing wasn't really smart. Besides, if we wanted to scale to hundreds of millions of users, we would essentially be using millions of dollars of resources per microservice. And we already had serious issues on our staging env as it was. I quit my job, which was hard. I haven't made as much money as I did back then and I was a junior then, I'm a senior now.
I have more horror stories with microservices lmao.
>>21032>I used to work at one of the Big 5 tech companiescool! I guess it was a good learning opportunity at least even if you didn't establish yourself there.
>"User" microservice, another for "user tweets", "user friends", "community belonging", etcmaybe I'm just too stupid to understand "enterprise architecture" but that sounds like a nightmare. like user and user friends at least and even the community part sounds like it belongs together, I can't imagine how slow it would be to fetch user data from one service then friend associations from another because these "friends" would just be other users in the system, same for community lists which are just association lists of users.
I have built microservice driven stuff which worked well enough for our purposes but we split them not by model but by responsibility so like identity management (users) being managed by one, file storage by another, notification delivery, log aggregration, gateway, and so on.
>Besides, if we wanted to scale to hundreds of millions of users, we would essentially be using millions of dollars of resources per microserviceyeah absolutely, microservice applications aren't cheap to host, especially in the cloud because traffic and db costs are where cloud providers make bank, and microservices need multiple dbs and lots of traffic between availability zones.
>I have more horror stories with microservices lmao.feel free to share lol. microservices imo are a good idea but there is a tendency to get carried away and over-engineer them.
>>21038Framework: 👎
Composable libraries of varying degrees of abstraction and escape hatches: 👍
ORMs: 👎
Relational data mapper: 👍
ORMs: 👎
Type-safe SQL DSLs that validate correctness with the database at compile time: 👍
Implicit configuration: 👎
Explicit configuration: 👍
Varying configuration levels, or no unified way of configuring things (XML, application.conf, via params on objects, modifying a global static class/runtime thread/execution context, annotations, compile time configuration, autowiring, HOCON): 👎
Unified configuration levels and mechanism: 👍
>>21008what exactly is wrong with spring boot? yes its heavyweight but i feel you MFers didn't live through the times when the lightest weight enterprise java frameworks were shit like JSF/ADF and JEE/J2EE where it took like 200 lines of code to send an email and 75%+ of your coding was editing XML files and running codegen.
Dealing with spring/spring boot at scale is still 1000x less painful than dealing with this shit. You don't have to use a lot of the automagic parts of spring if you don't want ex: the derived query names.
I'd rather have magic by default and do it the old fashioned manual way as an exception, rather than the other way around. Spring boot also has 10x LESS of an "over-engineering with design patterns" problem than old school java and it isn't even close.
Everything you whine about was a million times worse in pre-spring enterprise Java which is why spring was developed to begin with and why it's still preferred by comparison otherwise people would have already ditched spring/boot for NU-JEE frameworks like eclipse microprofile or quarkus.
>>21262>you should be killed desuDon't worry, I am planning to do that myself.
> picIs UML against autism?
>>21268>Is UML against autism?yes. middle managers and corporate climbers (aka non-autists aka normies) love pictorial representations.
line go up, data flow through colourful chart, little smiling people happy to participate in the flow of money from them to us!
>>21156I've been meaning to write a thoughtful response and have been putting it off.
Yes, pre-2010s web/webAPI frameworks were absolute dogshit. That's why rails took off the way it did IMO. The issue I have with springboot isn't that it pioneered a less painful way to build services. The issue I have is that it inherits a shit ton of that same old pain that other environments have already overcome for a large percentage of use cases. It is no longer in vogue to make huge monoliths that do a billion and one things, so the fact that springboot can do a billion and one things "out of the box" is more an invitation to shoot yourself in the foot, than to build maintainable, robust, and scalable systems.
Further, the fact that springboot has been around and has evolved a ton means that there is a million ways to do things. In an already very complex framework that hides configuration from you (convention over configuration shit, annotations with large amount of secondary behavior, etc) it leads to a complex system even when the codebase is not particularly large.
That's just one of the many reasons ORMs, particularly JPA+Hibernate in springboot world, are so harmful down the line. They are deceptively simple, yet under the hood provide a huge amount of derived and secondary/managed behavior that has an impact on the semantics of your program. Put another way, it's like you're putting your humble PetStore model, and by annotating it with @Entity, you're strapping it into an iron man suit of functionality. PetStore.openForBusiness() isn't doing a simple operation, it is ramping up some nuclear powered core to open the fucking thing, and maybe its open, maybe its not, because the transaction is managed for you, and flushing can happen randomly, or maybe it doesn't, you'll need to read the entire documentation on whatever function you're using to make sure that there's no unintended side effects.
This is what drives me nuts. The unintended, implicit behavior that ShouldJustWork™, except that when it doesn't you'll be balls deep into figuring out how to coerce your ORM to act like a sensible relational mapper that you actually have control over. Same with all the implicitness and million ways to subtly configure behavior everywhere. It's ridiculous!
>>21273the computer autists I know spend 90% of their time at the command line and in text editors.
go make some burndown charts or something for your next productivity catch-up with your normie handler.
>>21281rofl at believing programming requires some sort of advanced abstract thinking
>if you dont agree with me you must be part of le outgroup that lives rent free in my headi dont care about your shitty job, its just funny that you think youre a special boy for being diagnosed with mental retardation lol
>>21284>believing programming requires some sort of advanced abstract thinkingnever claimed that. stop fighting against the imaginary nerd you have in your head.
>i dont care about your shitty jobthis entire thread is about something people commonly do as a job.
my dislike for charts and graphs is also because I need to make them at my job and I don't enjoy it.
>>21312>Fuck k8s lol.the problem isn't this shit but the fact that everyone is running to the AWS one man band model where you have to do the job that 4-7 people did in the 90s.
develop the front end, back end, database, cloud engineering, system admin, QA/testing, build /delivery pipelines and work oncall supporting it in production.
"devops" in practice either means rebrand ops as devops with no change, or more often, "just make the devs do all the ops work".
>>21325It's exhausting. I've taken the route of basically avoiding learning terraform, k8s, or beyond the basics of Kafka. Also with a bunch of other shit. I've chosen my battles. But now as a senior it seems increasingly like a barrier to progressing the ladder. I can't bullshit my way so easily anymore.
Which is part of the reason I've been seething about spring boot. It's yet another complex, intricate, and nuanced framework that I'll have to learn to also run on top of k8s, with Kafka, and provisioned with terraform. Don't even get me started on the shit logging tools like Prometheus/opentracing, grafana, etc.
>>21353it's a desperate trend to go back to the 90s where everything was so ossified into these specializations. you couldn't do anything with the db, the DBA was supposed to, the architect would make all these crazy charts with data structures and you were just supposed to mindlessly convert them to code, you couldn't deploy your shit, a whole deployment team would need requisitions and little slips of paper to provision something where it could be deployed, half your shit didn't work because the network team would have to whitelist comms between parts of your large application, you couldn't choose the best tool for the job because your company had already made a deal with ibm(tm) consultants who would supply you with the right tools and wOrKsTaTiOnS.
there has always been a deep desire to turn the process of writing software into an assembly line with specialized responsibilities which can be broken down into measurable effort required and output produced so you can plot these trends about how many "man hours" will be billed for measurable deliverables (tickets, uSeR sToRiEs, etc) and present it at the end of every "quarter" with two nice coloured lines while dressed in your sunday best and saying things like "our agile methodologies have empowered consistent growth in our endeavours to deliver value"
>>21377>>21397Let me be clear here that I'm a senior software engineer. For entry level, knowledge of these things are not necessary, despite what reddit narcissists and HN boot lickers might make it seem.
And yeah trendy shit is so common as well. The company I work for decided to shift towards Go. Honestly choosing between Go and Java/Kotlin springboot trash, maybe I'd choose Go, but the arguments for Go are usually flat out wrong. For example, the promise of performance, most systems don't need to be fast. It is much more important for them to be correct, easy to maintain, reliable, and functional. Performance is usually only actually important in few scenarios.
>>21472>Isn't the whole point of devops to make the actual developer do the ops, too?yes but the question is
what developers. A Devops/SRE person is a developer that uses their coding skills to automate traditional IT tasks i.e. support and infrastructure (and now cloud). Basically a "software engineer with an operations focus". The problem comes when they try to make the person developing features also do everything else.
>>21450I just ignore that and apply to "minimum experience" on X shit. I expect to learn new things at work.
>>21473With shit like terraform, k8s, docker, among other things, SDE are expected to configure things like infrastructure (infrastructure as code, terraform), k8s shit, docker, etc. The more senior the more you're expected to perform. Every job is different of course and every country and market have different styles too. This is just the trend in top tech companies I've seen.
>>21896Do you have an example of the mailing list style change list?
Git is a very nice tool for version control. That's why people use github style PRs.
>>22068You can look it up:
https://referencesource.microsoft.com/#mscorlib/system/uint64.cs,bab4b7828a13e6a7https://github.com/microsoft/referencesource#net-reference-sourceBut it is normal to just accept the documentation, C and C++ programmers don't need to look at the implementation of atoi/stoi either, just read the manpage/reference.
>>22122Which one is your poison?
>>22068What do you expect it to do? Like whether it can fail or what? Or memory wise? Not sure what your expectations of int.Parse() can possibly be.
>>22126Java and C# overload classes as namespaces. In java Integer is the class containing an int value and also the namespace for the static function java.lang.Integer.parseInt().
The C# int/Int32 type is a value type/object but the same applies regarding int.parse() being the parse function in namespace System.Int32.
Unique IPs: 47