What the author is too young to realize is that there is no development path for him(?) as a programmer. Companies don't care if you have time off or hobbies, or a wife, or anything. They don't hardly give a shit that you need to breathe air.
Maintaining code quality when nobody cares
31–40 of 245 posts
Re: Maintaining code quality when nobody cares
#32> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
the javascript mentality! software isn't old until it breaks 10 yrs!
Debatable. Just as people, some software ages badly. Heck, sometimes it's just born old :-)
Re: Maintaining code quality when nobody cares
#33> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
I suppose it is for webdev. I regularly work on C code that's nearly as old as I am.
As an Elixir dev, popping open old Erlang code bases is always an interesting experience. Some of those haven't even been touched in the last 4 years!
Re: Maintaining code quality when nobody cares
#34> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
Not old. The author is probably young. Or a js dev. Or both.
Re: Maintaining code quality when nobody cares
#35> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
That is barely out of adolescence. Part of my day job is shepherding a large legacy web application into final retirement. 18 years and still trundling on, longer if you count the desktop applications that came before in the product line. Still getting new development time allocated to it too, most recently implementing improvements to help the clients comply fully with GDPR. Traced a problem in production back to a bug introduced 13 years ago just the other day...
Re: Maintaining code quality when nobody cares
#36Some things I've learned about code quality in organizations where the quality is terrible: 1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer. 2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? The…
A big problem in the IT world today is that #1 is no longer the case--it is marketing departments that are driving a lot of software development and they don't care about standards, code quality, tests, anything. It's a bad culture change.
Re: Maintaining code quality when nobody cares
#37> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
It is for the author who got his first paycheck last year.
Re: Maintaining code quality when nobody cares
#38> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.
My favourite quote from, "Working Effectively With Legacy Code" by Michael Feathers:
"They're writing legacy code, man!"
Re: Maintaining code quality when nobody cares
#39Earlier quoted context omitted.
If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.
The problem here is that you're making the organizational culture _worse_ while you make the code better. And it's organizational dysfunction that led to your situation in the first place. It's a dysfunctional organization that doesn't let you write quality code without lying (assuming you are correct that this is ultimately counter-productive for the organization's goals), and most every dysfunctional organization I…
So what's the alternative to lying for what you hope is the greater good?
This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them.
I'm not saying that lying is preferred, but what else can one do?
Re: Maintaining code quality when nobody cares
#40> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
[deleted]