Navigating a Broken Dev Culture
My Current Job is a Mess—But I Won’t Let It Define Me
(Disclaimer: Not here to trash my company, just sharing my experience.)
I work on the AI team at my current job, meaning I get to play with cutting-edge generative AI tech. I’ve built some pretty cool things: • Designed an end-to-end image generation pipeline for a virtual friend app. • Implemented self-hosted Stable Diffusion with Automatic1111, adding sentiment-based image optimization & image retrieval. • Used Vicuna (uncensored) + VLLM for serving our text model.
Sounds exciting, right? That’s about where the good part ends.
The Bad: A Tech Culture Stuck in the Stone Age
The engineering practices at my company are, to put it mildly, nonexistent: • Testing? None. Even revenue-generating products (~$200K/yr) are tested manually. • Deployments? Manual SSH into the server, copy the build, and pray. • CI/CD? What’s that? • Docker/Kubernetes? Not in our vocabulary. • Code Quality? Negative.
I’ve tried pushing for better practices—heck, I even gave a Docker session to the team—but there’s no buy-in.
The New Obsession: AI is Eating Our Jobs
Management (none of whom are engineers) has fully bought into the “AI replaces devs” hype. Our CTO literally said:
“Use GPT to write code. This is a one-day task; it shouldn’t take more than that.”
They genuinely believe AI can replace skilled developers overnight. Meanwhile, they’ve never used GPT to write production code themselves. They just read the PR spin and assume it’s magic.
Despite this chaos, I’ve refused to let the environment affect my growth. WFH helped me stay sane, but now that we’re back in the office, I know it’s time to move on.
I never had a formal AI background, but I self-learned everything while on the job. Along the way: • Cleared GSoC and worked on Intel’s ML toolkit OpenVINO (JS bindings). • Discovered OpenTensor (decentralized intelligence), cold-emailed a contributor, and worked part-time on his startup. • Got my Rust PR accepted into Docify (used by Polkadot). • Built a Rust + HTMX startup backend using Rocket (signed an NDA, so can’t share details).
What’s Next?
I’m scrambling to find a new job. Ideally, I’d love to work on FOSS full-time rather than jumping into another corporate dev job. The problem? Finding an opportunity that matches my current compensation in India.
I recently worked a contract gig for $17.35/hr—if I had a year-long commitment at that rate, I’d have left my job yesterday.
I know going full-time into FOSS isn’t easy, but if you have advice—or know FOSS projects that need contributors—I’d love to connect.
My stack: • Frontend: React / Next.js / TypeScript • Backend: Node.js / FastAPI / Flask • GenAI: LangChain, RAG, Stable Diffusion, Tool-Calling • DevOps: (Self-learning)
I’m in a phase where I can afford to push myself to maximize my learning, but I also need to be practical. If you’ve been through something similar or have insights on making a sustainable career in FOSS, I’d love to hear from you.
Thanks for reading—I appreciate any thoughts, advice, or connections!
> This is a one-day task; it shouldn’t take more than that
Your CTO is an idiot but you can't change that. My first idea would be to write a good resume and start finding another job. The whole description confirms that. I have worked for a lot of companies from the smallest to the biggest and it's always the same scenario. If everything is THAT bad, your only chance is to leave. It would take years to change that company, and you would have to accept a lot of refusal before anything changes.
Also don't focus too much on AI, there are a lot of good jobs unrelated to that topic.
I'm not an AI guy, but I would focus on what you don't know now and which may be useful in the future. Maybe Docker for the Devops and GitLab/GitHub for the pipelines (always useful), and some Python/uv/Ruff which seems missing from your description (AI scientists seem to love their Python).
You could add unit-tests and code coverage in JS or Python, and maybe a compiled language like Java/C++ or a functional language to get a broader view of other languages.
But all my pieces of advice are for what you would do at your next job. I tried to change companies before but I became bitter and found better elsewhere.
Last but not least, the skill that I lacked the most was the ability to talk to actual users or clients, and make sure that their demands/specs were well written and handled. It makes a lot of difference.
One thing I didn’t notice- what impact to the bottom line does kubernetes or docker bring?
I love shiny tools and containers as much as anybody, but “this thing is shiny and new age” isn’t a great pitch. Your team needs to have problems that kubernetes can solve.
If you don’t spend that much time on deployments, if outages don’t cost you much money- it is probably not worth it.
When I hear 200/k a year as revenue generating- I hear that this is something that should be limped along as cheap as possible, not that this is something that should be invested into and modernized.
I had the same reaction. I would look more favorably on a company that doesn't use Docker or Kubernetes. These tools, by default make things complicated and slower, so there needs to be a positive benefit for their use case that balances this.
It makes me wonder whether OP's desired for testing and CI is for a specific reason, (e.g. targeted test on certain algorithms, CI/CD to replace manual QC steps etc), or if it's for less-practical reasons.
> These tools, by default make things complicated and slower, so there needs to be a positive benefit for their use case that balances this.
I'm confused by this reasoning. How does Docker make things slower by default? Why would you look favorably on a company that doesn't use it?
Or At least with the second one, you have automatic artifact tracking for easier rollbacks.I would rather run software directly than wrap it in something, (and in this case, the wrapper isn't thin!) unless there are complex system dependencies. And that may be a smell of its own. Depends on the application.
But that's a personal preference. I was asking how Docker makes things slower by default? Like, the act of using Docker means software delivery will necessarily slow down.
Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc.
The build/deployment time difference is maybe the least relevant, but also there most of the time, because Docker performs more work than simple zip+scp and an scp copy of the version to archive somewhere. Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment, if application files are only ~1-2MB tends to add quite a few seconds to the process, although how much it matters depends on network speed of course. For example on my modest connection it'd be ~8-10 seconds vs <1 second.
There are of course great reasons to use Docker such as a larger team that needs a common environment setup or when using languages that don't have great dependency management system (eg they have non-transferrable builds between systems), but it is something "extra" to maintain.
Sure, in the grand scheme of things, though, I wouldn't argue that seconds is a legitimate slow down. I just really struggle to buy into the argument that "non-Docker" is superior and that introducing Docker is a problem. It's _another_ way to do deployments, and it's not strictly worse. There are tradeoffs on both sides, although I would argue Docker has far fewer than just using systemctl and SSH.
> Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc
Docker is available on every major distribution. Installing it once takes seconds. Accessing logs (docker logs mycontainer) takes just as long as systemctl (journalctl -u myservice). Maintaining a registry is optional, there are dozens of one-click SaaS services you can use you instantly get a registry, many of them free. Besides, I would consider the registry to have significantly more time-savings benefits due to being able to properly track builds.
> Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment
This is only partially true. Images are layered, and if the last thing you do is copy your binary to the image (default Docker practice), than it's possible for it to be exactly the same time as it's only downloading one new layer (the size of the application). Only on brand new machines (an irrelevant category to consider) is it fully true.
>I wouldn't argue that seconds is a legitimate slow down
Seconds are an eternity in the domain of computing.
But this assumes that Docker provides _no_ advantages in time-savings, which is simply false. The person who recently responded to me noted that themselves. There are several scenarios where Docker is superior, especially in cases with external dependencies.
My point is that the universal argument that Docker is inferior to manually copying binaries is flawed. It's usually put forward by people who fit in the narrow scenario where that happens to be true. If we can agree that both options have trade-offs, and that a team should pick the option that best fits their constraints, then I think that's pretty much where most of the world sits in thinking. There are extremists on both sides, but their views are just that, extreme.
I think you confuse "good" with "trendy", as the list of things you want is a bit of a mixed bag.
Testing is almost unquestionably a benefit (at least to a point) and is something that can be introduced with minimum initial investments and right away gives big benefits. I'd start with that for low effort, big impact.
Then CI (but not CD) is like that too. Just have the test executed on every commit/PR to gain some confidence.
CD requires a whole culture around it, and not everything fits into this culture.
There's really nothing wrong with deploying stuff via SSH. It's not most fashionable, but if done via script and works, it's OK. No need to fight it.
Docker can be great, but people often shove it where it is not needed. E.g. if I was deploying Java (standardized VM) or Go (static bin), I might not bother. It really was invented for Python, where it is impossible to get the Python app running on anything but the developer's computer.
k8s ... mixed bag. Hefty price in complexity, for some benefits that are sometimes important, sometimes not.
So one of your top-performing products almost pays the salary of a single developer? They’re not investing into any of it because none of it is actually profitable. It’s literally not worth putting more time into that bucket vs actually trying to make something people want.
OP said they are from India. Even within the US, outside the tech hotspots 200k is much more than a single developer costs
In the USA a fully loaded cost of a not-fresh-out-of-school developer today is very likely >$200k. You have to factor in benefits, insurance, equipment, licensing (Windows, GitHub, all the AI subscriptions, etc), space (RTO!), any stock, and taxes to get the fully loaded cost.
Roughly salary times 1.5-2 is a good ballpark depending on location and equipment/licensing needs.
IME Most of the good devs in India cost at least 20k USD, with the price going up based on seniority and definitely skillsets, a very sought after skill can still ratchet up costs - but even then we're talking something that is going to run 3 devs tops and not have a lot of room for additional investment - something has to be taken out of the system for someone to care at all about running it.
Right, 200k is ~16.6k per month or 500 dollars per day of rev, not even profit.
For most normal businesses this would support a lifestyle/single person type of shop tops, but essentially this would be considered either the very start or a complete dead end for any business with multiple people involved.
It sounds like the OP has some chops and definitely needs to find an org where their skills are more needed.
> Deployments? Manual SSH into the server, copy the build, and pray
I know people who would kill to be in your shoes. grass is greener and all that.
Email me at tim at transloadit dot com. We‘ll hire you to work full-time on uppy.io and AI for our backend services.
PS: GHA Deployments, CI/CD, PR Reviews, Gazillions of tests
I wonder the rate of which like-minded senior leadership is growing in our industry.
If this mindset spreads enough we will probably see many major software issues playing out in our day-to-day lives.
Some observations:
- This might lead to the job security / market pendulum swing in favor of software developers that we seem to have lost recently. Companies might start paying a premium for those of us who can debug LLM code and get businesses back on track.
- There may unfortunately be a disaster resulting in the loss of life that leads to the introduction of strict regulations on our industry (sure hope not).
Curious what others think.
Just FYI: Most jobs in FOSS are corporate jobs. As in, a corporation pays you to work on it, because they publish or sponsor the project. And the "easiest" way to get into that kind of position is to start the project yourself, or already be a major regular contributor.
It sounds like you need to find your way into a company that isn't broken. Just start interviewing?
Or figure out how to make your current environment less broken. Improbable if it's as you describe, but I don't know you. Things like testing and CI aren't stuff you necessarily need to "push for", it's stuff you just do. Just set it up and get a group of likeminded fellows to use it. Consensus starts with a small conspiracy of engineers.
> I know going full-time into FOSS isn’t easy
What matters is whether it’s important. I spent a lot of time over the years doing FOSS and learned all that code just like all other code atrophies and dies. Maybe it helps you get a job (mine did), and maybe it drives part of the world. But, eventually, it’s probably not important. Don’t worry about FOSS as criteria for a job doing something that is transient.
If you’re so motivated though, be Richard Stallman!
You can email me: aravind [at] coderabbit.ai.
We are hiring in BLR and SF.
Mistitled, I suggest. It only describes a poor work culture and the author is NOT navigating it and wants to bail. I came here to find tips on how to stay in a poor culture and avoid the worst pitfalls.
What made management decide to move back to the office?
Pretty sure they’re listening to the AllIn podcast
200k/yr revenue? Like others have said - basically they can't afford to do the things you want to do. All the things you want to do take time to make run smoothly and divert dev attention for a while, and it seems there is no time for that. It all may help in the long-run and actually help generate more revenue, but that won't matter if they go under in the meantime.
If you don't like that yolo culture, move on... you are not likely to change it.
money
The moment you started describing your office I knew this was India (I'm Indian too). sigh
I can only wish good luck, won't say anything more considering the kind of site this is.