> 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.

> Your CTO is an idiot

How can you say this without knowing what the task is?

thanks for your suggestions, I am well versed with uv / ruff , just didn't mentioned in my post , absoultely loved uv after trying it out. I have started looking out for jobs aggressively.

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?

  make
  scp mybin machine@foo.com/deploy
  ssh machine@foo.com -c 'systemctl restart myservice'

Or

  docker build
  docker push myimage@latest
  ssh machine@foo.com -c 'docker-compose up'

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 think the point is that not using Docker is easier, simpler, cheaper and better than using Docker.

Unless it is not, then you should use Docker.

But many (all?) of us have had the experience of a manager insisting on some "new thing" (LLMs are the current fad of the day) and if we are not using it we are falling behind. That is not true, as we all know.

It is very hard for the money people to manage the tech stack, but they need to, it is literally their job (at the highest level). We desperately need more engineers, who are suited (I am not!) to go into management

>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.

Testing is very important. But....

> something that can be introduced with minimum initial investments

Testing is very expensive. Setting up an automated testing environment is tricky, prone to failure, and requires constant expensive management.

It also adds nothing to the bottom line, on the face of it.

It is very very important. It is possible to limp along with inadequate testing, become a major global infrastructure provider, then have it all go horribly, predictably, wrong.

But the money person that commits large quantities of cash to something that does nothing to improve the bottom line tomorrow (fingers crossed) is taking risks with their personal welfare.

It sucks. Testing is very important. Automated testing is gold. It is very hard for us to implement because....

> Manual SSH into the server, copy the build, and pray

Doesn't sound like a script. Also doesn't sound like there's even a build server or CI.

yup none of the above :/

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.

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.

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.

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

> 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.

to add to that usually there is a proxy server in between to connect to the server you're deploying, which is means you have to scp twice and it's like the most dreadful thing , I'm not sure why did you said "I know people who would kill to be in your shoes." am I missing something ?

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.

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.

thanks for your advice ! , "figure out how to make your current environment less broken." I tried this , it didn't worked there's just too much politics to navigate so I just started looking out for a new job.

> Testing? None. Even revenue-generating products (~$200K/yr) are tested manually.

So, not none then.

:/ I was not expecting this

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.

Yup, I resonate with your opinions In fact, we might actually be in the middle of this playing out.

Check out FOSSjobs (TLS cert expired ATM) and especially their wiki for potential FOSS opportunities.

https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources

thankyou so much !

> 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!

that was deep :/

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?

no clear communication on that , but the back to office mail contained usual points like , collaboration is better in person etc etc , and that we're targeting to achieve big things in this AI wave so we all need to work togther and hence back to office lol ://

Pretty sure they’re listening to the AllIn podcast

maybe lol !

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.

us bro !!

money