money
Navigating a Broken Dev Culture
21–30 of 49 posts
Re: Navigating a Broken Dev Culture
#22So 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
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.
Re: Navigating a Broken Dev Culture
#23I 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.
Re: Navigating a Broken Dev Culture
#24Earlier quoted context omitted.
> 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…
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.
Re: Navigating a Broken Dev Culture
#25200k/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.
Re: Navigating a Broken Dev Culture
#26The 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.
Re: Navigating a Broken Dev Culture
#27Earlier quoted context omitted.
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 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.
Re: Navigating a Broken Dev Culture
#28Earlier quoted context omitted.
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 d…
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.
Re: Navigating a Broken Dev Culture
#29Earlier quoted context omitted.
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 d…
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 addit…
>I wouldn't argue that seconds is a legitimate slow down
Seconds are an eternity in the domain of computing.
Re: Navigating a Broken Dev Culture
#30Earlier quoted context omitted.
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 addit…
>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.