/tech/ - Technology

Am only conducting self-criticism here but:
- No planning, just pattern recognition, search, trial and error.
- Constant need to "innovate", feature creep.
Probably just too poor to plan and to not innovate.
Of course it doesn't help that often "you're the product".
Or maybe even the idea of a product is a problem.

>>29909
There's basic trial and error (something everyone does) and then there's apathy and gross negligence. I literally came across hardcoded passwords in client side JS at my workplace. This is in a finance app btw. It takes an extreme level of retardation from the techleads and product managers to allow such shit to pass.

>>29910
>Most of the teams I have worked with are filled with careless assholes.
>Techleads and product managers allow such shit to pass.
>How does this happen.
To rephrase what you've written it sounds like there's a lack of "accountability".
It's funny to imagine a culture of blaming subordinates being productive.
An alternative is just to assign work to subordinates appropriately to get (reviewed) results.
Problem with this is you might develop lots of dead weight.
This probably goes back to hiring practices; crazy turnover is good for no one.
Maybe if labor was more expensive they couldn't take it on to begin with! (Yugo)

>>29908
There are better places than others. The current company I work for, a big tech company, has terrible engineering practices. It's a really complex issue, there's several competing interests that are hard to reconcile and usually the business interest is overpowered. Further, this produces a culture of shit code. Plus there's even more factors related to employment and employee satisfaction leading to burn out and high churn which also feeds into this. Plus it is a highly specialized field that has pressure to deskill, which is part art, part social, part theoretical, and this mixed with good salaries makes snobby elitism, which peer performance evaluation just makes worse.

Essentially it's a shit show. Better to learn to play the game and fight for what you want. At the end, it's not much different to other desk jobs, and office politics can be used to your advantage if you manage to harness them.

Why can't they just standardize this shit? Just form a committee that solves CRUD once and for all.

>>29908
work for a while in one of these companies with imploded codebases, you will understand why.
it's mostly because of a mad rush to add features without regard to anything else because "business has committed money in marketing and press expenses for 231232 new features by tomorrow"
nobody cares to spend time writing proper code in an environment like that because it's not worth anything.
i have seen people resist automating mundane tasks like deployments or infra management because it's not "business critical".

>>29928
>it's mostly because of a mad rush to add features
Mostly this. Also incompetence and negligence.

>i have seen people resist automating mundane tasks like deployments or infra management because it's not "business critical".
Lmao I know this too well. It's not business critical until it fails.

Real question is: OP, is the pay, benefits, hours generally better in fintech compared to other codemonkey/IT jobs?

>>29931
Depends. Newer D2C fintech product companies tend to far less shittier than B2B service companies. As of now, I'm stuck in one of these service companies and I hate it. The pay sucks and the work makes me want to pull my hair out.

>>29916
It's all business and managerial staff's fault. Also "Agile". Both combined pressure you into pushing out garbage code that works in the short term but eventually becomes so messy it needs to be re-written. When that time comes, the cycle repeats itself. By then, everyone who originally created the mess will have moved on to something else, so good luck holding anyone accountable.

not very funny picrel.

>>29908
Youtube is "CRUD" but they are not putting video files on a random VM. It's an automatically scaling system. You'll find that almost every tech company has a lot of unique problems involving tech debt and domain specific stuff.
Your post is indicative of how developers or so called "software engineers" oversimplify problems to the point of absurdity. If it's so simple just go rebuild youtube. Go rebuild all these CRUD apps. You'll find there's tons of issues regarding regulation, getting customers onboard, etc. All that contributes to why the code base gets into that state. CRUD implies the app itself is already pretty complicated. It's a massively concurrent distributed system.
>>29916
We sort of have. That's the point of k8s, grpc, openapi, managed cloud services that all resemble each other, distributed databases, and standardizing on linux as the server-side OS.
As I said you just don't have a job so it's not obvious why but the service you're building in class is not comparable to the one that business maintains and extends.
That being said you do have guys like Lichess who make a service that appears to be comparable to Chess.com with 1/500th the budget.
Pirating a textbook + using anki + pirating immersion materials is more effective than Duolingo for learning any foreign language despite Duolingo having a 25 billion valuation. However, this is not because Duolingo is not a technically solid project, it's because Duolingo fundamentally fails in concept and the only way to learn a foreign language is immersion at the end of the day.
>>29935
Also you have this fucked up incentive structure. If you make the product too good someone will just buy it and lay you all off. Look at Twitter.

>>29934
>I literally came across hardcoded passwords in client side JS at my workplace
This is a unique level of negligence I have never seen at a large tech company

>>29982
>Youtube is "CRUD" but they are not putting video files on a random VM.
Agreed, but the vast majority of sites are not YouTube and will never be. A simple setup consisting of a monolithic frontend, a monolithic REST API, a singular SQL database and maybe object storage of some kind covers the needs of 99.9% of web apps, asynchronous processing and caching optional. But I've yet to come across any in-production application that just works, despite having the exact same architecture.

>Your post is indicative of how developers or so called "software engineers" oversimplify problems to the point of absurdity. If it's so simple just go rebuild youtube.
NTA. Btw, I work at a small B2B SaaS startup. The applications here handle nowhere near the amount of data a big social media site does, but they still suck. Of course large distributed systems are complicated, but keep in mind that the vast majority of websites still use WordPress. The level of complexity you're talking about doesn't exist even in most tech companies.

>We sort of have. That's the point of k8s, grpc, openapi, managed cloud services that all resemble each other, distributed databases, and standardizing on linux as the server-side OS.
I have yet to come across someone using kubernetes or grpc in a way that isn't cargo-cult retardation. Heck, I have yet to come across anyone even uses docker properly in production. Technologies on their own will never standardise shit. It's the management that needs to take initiative for that, which they never do.

>>29983
It's common practice in fintech in my country (I'm Indian btw lol). I remember seeing a tweet from some cybersec guy who found the production environment credentials for one of our government owned banking websites in an plain json file that was open to the internet. Shit like this happens all the time, you don't even know the half of it.

>>29993
>>29994
I think my issue is that I've worked in big tech so long I assume people aren't totally retarded. Most of those problems are fixed by paying more for better devs.

>>29994
>It's common practice in fintech in my country (I'm Indian btw lol).
no it's not lol.
what is it with indians and the self-deprecation and loathing?
dumb security lapses are common all over the world, it's not "common practice" anywhere. government and large corp contracts for building software are often riddled with corruption and some inevitably end up with these issues.

>>30002
>Most of those problems are fixed by paying more for better devs.
better devs and giving them the chance to implement things according to their knowledge and understanding of your problem. not cargo-culting by hiring devs and then telling them linkedin raised profits by using a message queue or microsoft stock is up 50% because AI now writes 80% of all their code, so you must find a way to implement message queuing or using AI "agents" to build stuff faster.

funnily so far it hasn't occurred to them to simply not hire any devs and use an AI "agent" to build their async queued event driven 30 billion dollar unicorn idea.

>>30006
It has nothing to do with self-deprecation. I have startup founder friends who refuse to work with Indian clients, despite being Indian! They really pressure you that much and don't hold anyone accountable for anything.

>>29993
>kubernetes or grpc in a way that isn't cargo-cult retardation
GRPC absolutely. it's really not that much of a leap over other RPC protocols.

but kubernetes can be very nice if used in the right way. First of all it is self-hostable, you don't need cloudshit lock-in, second, it can be run on the cheap if you know what you're doing, and you can get pretty reliable scaling and robust and repeatable deployments once it is all set up at the outset. A no-brainer at this point if you have any application with multiple interacting services. Yes, it is kinda ugly if you really get into its configuration and logging but these days you get nice UIs like rancher to abstract that mess away for day-to-day operation at least and you won't need to deal with that unless something goes seriously wrong.

>>30008
I've never felt pressured to deliver at my current big tech role before a product is done. We're happy using old proprietary stuff if it works.
When devs job hop every 2 years I doubt they've seen the ramifications of their work. Tons of microservice resume driven development bullshit as if the next shmuck who shows up will know rust or want to learn it. They seem to include tech simply so they can apply elsewhere with it on their resume. In some domains it takes 2 years just to get sufficiently acquainted with regulations, the business itself, etc.

We don't use AI to write code that much because code gen + libraries/etc. are enough for us. Rarely I'll use LLMs to get an idea of how to write something. In general I think frameworks solve the problem much more elegantly than an LLM. Better to have unit test/performance testing/etc. on everything, centralized in a library than duplicated 24/7. The people who shill LLMs seem to work in small code bases with little to no domain expertise required.

I think a lot of devs give up and start telling management what they want to hear while they insult them behind their backs. What else can they expect when management is pretending AI can replace a dev, it's insulting. Zuck claims mid level engineers are gone in a year. Lmao. I hate these people.