> Actually, i don't have enough time to do my day job, learn new technologies [...]
>
> Ergo, i cannot update. Ergo, companies cannot ship features AND handle all of the updates [...]
Your time is limited and you can't get more of it. That isn't the case for a company. There, time == money, because if their employees don't have enough time to do all the work, they can just hire more to do the rest. But because they're only interested in growth and not sustainability, most of that money goes into developing new features, not keeping up with security updates. The vast majority of large companies could very easily hire one engineer and task them exclusively with updating legacy dependencies. And the smaller ones could instead re-task half their dev team for a month each year.
> If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough
I've noticed this to be a huge issue when it comes to large companies who try to defend the situation saying we are "lean" and reduce forces by "cutting the fat." I'm currently in a situation where I've become "The Guy" for two entire product lines and its gotten to the point where they keep tempting me with "You'll be on Next Generation SOON". But soon, in my eyes, will never come because I'm a single Engineer maintaining hundreds of thousands of lines of code, code that deals with an OS no one else uses, in build environments no one else uses.
What I use to think of as job security has become a pill that induced boredom.
> actually keeping something alive (let alone building new features or making those features work) takes more and more man hours.
And the people who made the brittle architectural decisions aren't the ones suffering the fallout increasingly often; with companies shunning internal promotions and substantial raises, more and more developers turn into nomads who switch companies every other year just to keep up with inflation. They rarely if ever get a chance anymore to grow with a single codebase and learn what makes it stable and easy to iterate on long term.
>As a software engineer can you imagine supporting every version of your software you ever released? Sounds like a nighmare.
This would teach us developers to do better.
Like don't push random updates that break shit. If your product is not filled with security issues you should be able to backport a fix for that giant secuiry bug you found, you can ignore the crashes. Anyway this big companies can afford to pay you to backport some fixes . It is not like some volunteer is forced to backport fixes in his free time.
>Your team will not do that because it's a job security to them
Every team I've ever been on [albeit that's only two], it's the opposite, if the devs had their way they'd spend all day every day simplifying and refactoring. The only reason we don't, is because actual business needs demand attention.
> Clearly you're not going to be working on bugfixes, so why should it be deployed?
What makes you say that ?
> And my devs generally like me.
And half of the world likes Kim Kardashian so what ?
> But when someone demands that I write scripts to prove all bugs I find, they can fuck off
You are not being proffesional then. You demand time of others to do your work, because, hej, you do your best, right ? Your managers decided to leave you out on arch decisions so you think all managers are like that. You extrapolate your slow and unworthy experience to everybody else.
The point is, there are almost no single time events in enterprise. Everything you do, somebody will have to do again, tomorrow, a few days from now, or a year later. So, if you do the things your way, others will have to repeat what you did (or you, or worse, somebody new who knows nothing about it but could get your script with simple Redmine search along with some 'historical records' - read the TMMM and see how communication/tutoring is important - feel free to watch Galaxy Quest later) and that is not a nice thing to do in a company - you are wasting our time, resources, customers etc., on the long run: https://xkcd.com/974/
You can do whatever the fuck you want in the company of your grandpa, but its about time you sysadmins understand that good sysadmining means understanding the code concepts and development tools, and ability to script in the middle of the night. Nobody will ever ask you to write Gherkin tests, Performanse test, unit tests, integration tests, to know OO patterns etc... But in my team I will demand you know how to write 50-100 line scripts. If you can't do that, then you are emberresment for your proffession.
Good time to quote Jeffrey Snover: "GUI-only, Click-Next, no-value-add Admins will be replaced with a new type of Admin - the kind that greet you the lobby".
When you start to experience this paradigm shift, you will soon find yourself thinking about how did you live before that, and maybe even buy me a beer for letting you know that you can improve.
> I was spending more time wrestling with package managers, version conflicts, obtuse configuration files, pointless deadlines, egotistical colleagues, and almost zero time solving interesting problems on products that I care about.
That squares with my experience of software development. It's like being a furniture maker but spending 80% of your time fixing your goddamn hammer because it keeps breaking and no better hammers exist, or consulting glue-drying tables because they keep changing your glue on you every hour or two and for no good reason every single glue performs differently while accomplishing the same thing.
... and then most of the remaining 20% is meetings and communication, which would be fine if you had more time to do the thing you're actually trying to do.
> I work at a wholesale insurance company (middleman); we have over a hundred individual systems, some simple, some quite complex. Some of those systems can be maintained by any programmer that comes in. Others really shouldn't be maintained by someone who doesn't have good experience in writing maintainable code.
It sounds like you have far too few developers to cover those systems. My company is similar, although with much fewer individual systems. The biggest problem we have is that we expect developers to be familiar with all of them and it's simply too much ground to cover, especially when you add in decades of technical debt. I've been there over a year now and picked up almost no domain-specific knowledge because the cognitive load of all the projects and their intricacies and the constantly switching between them is just to high to learn anything in detail.
The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.
> I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.
I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed? Were they being kept busy with other tasks which you consider lower-priority, or were they just sitting idle?
> but I believe there are too many developers because there are, in general, not enough jobs
True, but that is sort-of hidden under development methodologies and frameworks that enable untalented people to do less with more. It's also compounded by the fact that companies are horrible at hiring and making software decisions.
> the people in power, seeing this, are just after a massive cash grab
Well, people are always trying to do cash grabs, but in this context I can't help but wonder if the software development ecosystem is maybe exhibiting an unconscious immune reaction to our increasing obsolescence. I've seen different fields react differently to it.
In a typical office environment, there is maybe 1 hour of actual work going on per person per day, yet companies are not getting rid of those people. You already mentioned medicine, here the immune reaction is generally a quasi-religious aversion to change, even where that change saves lives or improves quality of life.
In software, it's on-site basketball courts and clueless people with meaningless university degrees spending their days tricking bloated frameworks into performing trivial tasks.
> The notion that anyone in a modern software development job would care about the specific hours someone spends in a seat is ridiculous to me.
Sure, but I do expect that folks on my teams are spending about ? of their lives—or 8 hours/day—working. I've been on teams where the majority of the team appear to spend about 6 hours a day actually in the office, and don't appear to be working (although of course they may be thinking/reading/learning) more than that.
That seems undesirable.
> You're either getting shit done or you're not
It's not a boolean; it's a rational. One gets so much quality stuff done over time. Those who produce more quality features over less time are more valuable than those who produce fewer, more broken features over more time.
> If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
Some companies that do web development (commercially, internally, or whatever) have tighter release schedules than the cool DevOps style Continuous Deployment that we see the unicorn startups like Basecamp, GitHub, Slack, etc. doing where code can get pushed to production a dozen times a day. The place I work at has governmental regulations and SLAs we have to comply with when we deploy, which puts us on a cadence with something akin to Chrome's release schedule (e.g., Dev is CI/CD, QA is CD, UAT is kept to about once a week, Prod is every 4 weeks with capabilities at a 2 week hot fix window). Additionally, we just don't have the resources or budget available to keep one developer twiddling his or her thumbs all day waiting for new buttons to show up on a browser control that we have to hide or mitigate the impact of.
I completely understand what your argument is, and it's valid. We have QA run integration, regression, validation and smoke tests any time code is promoted up the environment chain that tries to catch issues like this, and we do our best to keep on top of it all. This issue isn't something that effects us, but it shows a reactionary approach to dealing with these issues. Teams that do spend their time reacting to changes like a new button, or an underlying OS update breaking some compatibility or what-have-you have always been a thorn in my side. It's no way to deliver value to their customers since their time is consistently being hijacked from new features to put out fires, which is stressful and leads to burn out very quickly.
Tbh, I maintain a several-million-dollar-a-year project with essentially no IT resources besides myself and my requests are reasonable.
At this point, three developers [including someone my boss really, really was hoping would replace me on this] have failed to handle this project effectively.
So it isn't just luck.
> Would you say majority of devs have it like you?
The Devs I know personally do but they are largely my coworkers or my coworkers at previous employers.
> Because I've experienced the working hour issue. And that's not even at a startup.
Yeah, its probably because I've been largely self-managing with hard deadlines really only when we have contractual changes.
> why is it fair that you only support a hand-curated list of projects and ignore the thankless dev writing all the little helpers and utilities that save you time over and over again?
The little guy is exactly who I’m worried about.
Projects vary in number of developers, their financial arrangement, and the time that it takes to maintain a package.
I use an authentication package that is painstakingly maintained by one independent dev who kicks ass. He deserves more than a package like leftpad. Or a package that is developed by salaried engineers as an API for a product I already pay for.
> How do you reconcile believing that you improve your software against the idea that others make theirs worse?
It all depends. As an employee, I just accept that there's little I can do about the whole situation because the causes of it are things I have no control over[1]. This issue is actually one of the ones that gets me thinking that there isn't much room for engineers like me in the software industry anymore.
With my own software, I do have that control, so I avoid the practices that I think are leading to not optimizing for quality.
[1] In my current position, my employer does not engage in the practices that I think are problematic, and I am proud of the quality of our work. But it's a special case because we produce industrial machinery and the software has to be rock solid when shipped, constant updating isn't possible, etc.
>> less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work.
In the last five years or so, I've done contract work at several large corporations. In every single one, they didn't care about defects or code structure. They just wanted to ship an application in a very short period of time.
When I asked about the same thing you pointed out, the response was the same, "We don't care about defects once it's released, and we don't care what the code looks like. It needs to work well for our end users, nothing else. Besides, in 6 months, we're going to redesign and rebuild it anyways."
It just seems nobody cares about long term maintenance, and likewise, they don't care much about the code or the amount of defects that code is generating. Pretty maddening when you think about it. Nobody cares about quality anymore.
> Do you want to sit around waiting to be told what to do or engineer your own path?
It can be very difficult if not impossible to engineer your own path in most environments these days. These days most devs are simply trading time for money. If the backlog board is empty, they're on retainer waiting for it to fill up.
Because of the eternal effort of the enterprise to commoditize developers they're given no decision making power. So even though they continually identify work that could be done to improve product or process, they know it's a crap shoot to follow through on such work as it's more than likely to be rejected for one subjective reason or another.
> I just don't expect todays developers to make a herculean effort
that isn't supposed to be a herculean effort -- if it is then you should question those that provide the software stack, and question why you're beholden to those decision-makers.
> Most developers probably don't care and just want to get paid. Beyond that, I imagine you're not usually empowered to make big changes unless you're relatively senior, and even if you decide to be the kind of developer that's always striving towards self improvement your job is unlikely to reward you for your skill development.
Bingo. I got a release coming up, I just need to ship this -- ain't got no time for fancy stuff, and higher-ups don't want fancy or flourish, just make it work. And even if there is room for trying something new, it probably doesn't matter if the users DGAF about the new feature.
Your time is limited and you can't get more of it. That isn't the case for a company. There, time == money, because if their employees don't have enough time to do all the work, they can just hire more to do the rest. But because they're only interested in growth and not sustainability, most of that money goes into developing new features, not keeping up with security updates. The vast majority of large companies could very easily hire one engineer and task them exclusively with updating legacy dependencies. And the smaller ones could instead re-task half their dev team for a month each year.
reply