
Maintaining code quality when nobody cares - fodoj
https://mkdev.me/en/posts/5-recommendations-on-how-to-maintain-the-code-quality-and-keep-your-self-development-when-nobody-cares
======
ManlyBread
I've tried this approach in the past and and it has made me very bitter.
Eventually I realized that the company I worked for enforced no accountability
for bad code, so I would often open the solution later and found a pile of
ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and
no one is going to pay for it". Eventually you come to a conclusion that if no
one cares then why should you? If any effort on your part is going to be
negated by your coworkers anyway then why bother? How do you push back against
a corporate culture that has been there for years and no one seemed to have a
problem until you came along? Maybe it's possible when you're a senior dev
that has control over a project, but as a mid level developer I've never been
successful at enforcing any standard - people usually don't care because it
would mean additional work and effort on their part and they still get paid
the same regardless of the quality of the code.

~~~
reaperducer
It can be very frustrating, but ultimately it's a reflection on you.

Whether you're a coder, or a librarian, or a janitor, take pride in your work.
Do the best job you can.

If everyone else's code looks like crap, that's on them. When new people come
on, they'll see your work compared to the slackers, and start emulating you,
not them.

Like anything in life: Do the right thing, even when you're surrounded by
villains.

~~~
nightski
A contrary opinion based on experience - instead of focusing so much on how
bad the code is take the time to get to know your coworkers better. Talk with
your manager and the business leaders about the business. Learn more about the
business you are in and how your code makes an impact to that business. At the
end of the day the goal is not to produce clean code. It's to make your
company successful.

I'm not saying code quality doesn't matter, of course it does. But there is a
bigger picture and if you don't take the time to become a part of that you
will not be very relevant.

~~~
zoul
I agree, but it seems to me that being dragged down by technical debt is
massively more common in our industry than missing important deals because of
excessive emphasis on clean code?

~~~
ravenstine
Our industry is pretty hilarious in this sense. In school, it's expected that
you go through multiple drafts to complete an essay, and usually those who
skipped that process paid a penalty. Publishing is a high speed industry, but
time is still set aside for revisions and editing. These same standards seem
to rarely be applied in programming, I guess because our work isn't seen as
writing communication. We make computers "go". Because of that, we are too
often writing and reading each others' rough drafts.

------
ComputerGuru
There needs to be a sense of ownership and pride. Even my side projects are
written then rewritten over and over again until I’m personally satisfied with
my approach and the quality of the code. If I use a hack to get something done
on code no one but myself will ever see, I still leave a shame comment
(//mqudsi: this is an ugly hack because I was too lazy to clean up access to
this global variable. Fix me.)

We aren’t dealing with anything new in terms of work ethics and quality
control in software development. I maintain my code quality the same way a
carpenter 2,000 years ago would have cared about how well the insides of a
finished product are designed, whether it exceeds its required specifications,
what other carpenters would think of their work, how they would feel if a
future apprentice or master saw what they created that day, and so on and so
forth.

Additionally, I place a premium on “skills learned or perfected” over “bugs
closed or features implemented.” If xx is better implemented via an approach I
haven’t used before - well, here’s my chance to learn how to do that. Sure,
it’ll delay the process. But that’s where technical debt comes from. I may
only end up writing ten lines of code that took me 17 hours to figure out and
understand, but if those are the _right_ ten lines of code then whatever else
I could have or would have written or accomplished in those 17 hours doesn’t
matter.

When the goal is “closing JIRA issues or GitHub PRs” and the only metric is
how many bugs you closed that day, code quality will suffer. But instill that
sense of pride, take ownership in your work and create an environment where
others are encouraged to do the same, and it’s a different matter.

~~~
ionforce
> I place a premium

I think the problem is are you saying this as an individual or are you saying
this as someone in leadership with power.

Place a premium all you want. But if you're a grunt, that opinion is going
straight to dev null.

~~~
laythea
I laughed at this :)

------
dep_b
You need to get the programmers together and agree on a coding guideline, a
linter and other architectural fundamentals.

Then the gardening phase begins, which means no refactoring or warning or
style fixes unless you touch the code to do something meaningful like a
feature or bug fix. Leave everything you touch better than before. Dissolve
big classes and functions into smaller ones. Write a test or two for the
smaller side effect free function you just created.

It takes a ton of time and patience but every week the kraken loses a
tentacle. And once most code feels untangled you can embark on a refactor
since all of the parts are movable now.

~~~
aalleavitch
This is absolutely the situation I am in right now, and I desperately need all
the guidance I can get. We’re talking thousands of lines of React components
that rely regularly on manipulating global js variables, mixed with MVC 5
written in Razor delivering variables in script tags, mixed with outdated
jQuery, that’s all just concat’d together with gulp and that hasn’t seen a
refactor in years of changing hands with no style guide. The company started
in 2004 and I swear some of this code is still floating around from the day it
started. We have three sets of scss breakpoints, three or four layers of
“common.scss” files that act like a piece of furniture that has been painted
over dozens of time (with shit like * {padding:5px} floating around), and an
unknown amount of dead code. There’s lines written back-to-back with vastly
different styles (with a random distribution of semi-colons and arrow
functions and etc), and major global variables named with misspellings. And
while I clean this all up, I am expected to continue pushing out features and
addressing serious bugs with stop-gap measures.

Please advise.

~~~
WorkLifeBalance
Personally I thrive in this kind of environment, it's a kind of comfortable
chaos. MVC5 is positively modern compared to many of the products I've worked
with which have included (within the last 5 years) VB6 winforms but mostly
aspx webforms.

Understand that previous developers might not know what a DOM is have likely
written ad-hoc jquery snippets, included 3 different versions of jquery-ui
until they happened across the right combinations of versions to get their
plugins to play and will have a mentality of "it was working".

Given that, here's some advise on how to stay sane:

1\. Read and "Digest Working Effectively with Legacy Code" but accept you'll
likely not be empowered to actually implement the changes.

2\. Understand you'll have a grace period of ~6 months where you'll be far
more empowered to make changes and get suggestions pushed through, after which
you'll likely find yourself worn down by the system and more accepting of the
status-quo. Leverage this time if you can.

3\. Try to identify what caused the product to get to the state it is so it
can be avoided for future products. If it's something you're not empowered to
change such as "bad hiring policy" try to work out how you can spot that in
future interviews.

4\. Be pro-active in looking for bugs, particularly security flaws. Finding an
IDOR which lets you get cross-account data is usually fairly straightforward
in these kinds of environments. Doing so gets you noticed so you're not just
another cog in the system and can provide real value. Be careful not to put
others' out too much while doing this. It sounds like you only work on the
front-end but even what appears to be front-end can have security implications
such as template-injection.

5\. Draw a line in the sand. Be entire accepting in legacy code but if someone
is working on a new part of the product or is fixing a bug in legacy code be
absolutely ruthless in what you'll let passed in code review. This may not do
you any favours socially but a reputation for harsh code reviews isn't all
bad. For one thing you'll have to do fewer code reviews.

6\. Don't bite off more than you can chew. Treat it like a giant knot and
don't be tempted to pull at threads unless absolutely necessary. Instead wait
until given strong reasons for refactoring.

Edit: formatting, because HN doesn't do markdown.

~~~
testplzignore
> if someone is working on a new part of the product or is fixing a bug in
> legacy code be absolutely ruthless in what you'll let passed in code review.
> This may not do you any favours socially but a reputation for harsh code
> reviews isn't all bad.

In my experience this is the most important thing. I particularly focus on the
"what the heck does this code even do" aspect - the person who is modifying
the code needs to be able to explain exactly what the code does and why it is
correct (don't accept "it compiles and the one unit test we have passes").
Forcing the team to understand the code will make it very difficult for them
to continue adding bad code to the pile, as they won't be able to explain what
they bad code does, or will realize the code is bad in the course of trying to
explain it.

~~~
s73v3r_
It is very, very important in this situation, however, to not be outright
mean. Do not let anything through that you would not be comfortable
maintaining, but don't be a dick about it. All that will end up accomplishing
is that you'll be blamed for things not going through, and then you'll lose
your credibility as steward of the code. People will go over your head to the
boss, who will just make you pass it.

------
crdoconnor
Some 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? They can't tell. They
will usually default to seniority (meaning how long a developer has been with
an org, not how good they are).

3\. These organizations reward fires that are put out. They do not reward
fires that were prevented from happening in the first place. Those "senior"
developers will frequently be rewarded for putting out fires they caused.

4\. If you do a lot of work that prevents fires and that means you weren't
working on features or bugfixes, you are going to get punished, not rewarded
because to the people above you it looked like you were doing nothing.

5\. If you're going to do this kind of work, you need serious intrinsic
motivation.

~~~
maxxxxx
In general I agree with your points. But you seem to have some gripes with
"senior" engineers. I think if you left that out your points would be better.
In the end it comes down to management not understanding the work and
rewarding unproductive behavior. This has nothing to do with "junior" or
"senior."

~~~
l_t
While I haven't personally worked at such a company, I've observed some
"toxic" workplaces and found that typically it is, in fact, the senior staff
who are the biggest part of the problem.

Only certain types of people achieve seniority in a toxic organization, and
they are typically those who (deliberately or incidentally) benefit from the
culture that everyone else hates. They build a clique and try to build
influence while the new hires -- who actually care about doing things well --
turn over every 3 months.

This is all anecdotal, of course, but I do think that in an engineering-
hostile organization, the senior staff should typically take the brunt of the
blame (just as in a successful organization they would take the lion's share
of the credit).

~~~
maxxxxx
I guess that makes sense. If the org is dysfunctional the best people at some
point will have left leaving the not so good people.

But I think that change often has to come from management. Even if you are
senior you often can't do much about stupid management other than leave.

------
pgsandstrom
> 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"?

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

~~~
jimmy1
In my opinion, when speaking of "legacy software", we should place a stronger
emphasis on the actual meaning of the world _legacy_ rather than the usual
pejorative. Meaning that: this software has created a "legacy", in some form
or fashion. Whether that legacy was it was used in the past to build the
business, it paved the way for some standard or better practice, or it simply
outlived it's time.

Downvotes are usually reserved for when a comment is low quality or not
relevant to the conversation at hand. Could you please explain if my comment
fit into these categories for my own learning? Thank you.

~~~
eitland
Like it or not but legacy has taken a new meaning in software.

I think it is Michael Feathers who defines it as code without tests in
"Working Effectively With Legacy Code".

(That said, I didn't downvote you and I'm also tired of the abuse of the
downvote button. I think in your case they downvoted because it seemed like
unproductive nitpicking.)

~~~
jimmy1
Oh I know, that's why I am rebelling! I think words mean very specific things.
I know it may seem like unproductive nitpicking, but in my experience the
hundreds of discussions I have witnessed and been a part of myself in
discussing legacy systems, bringing the pejorative version of the term to the
table usually hinders the discussion more than anything, and it is this
attitude that greatly contributes to the "software is eating the world"
problem we soon to experience with everyone recreating the same library every
day instead of reusing existing, proven solutions -- talk about unproductive!

"Back in my day", legacy systems were admired! I mean, heck, they were still
there because some team(s) were using them every day, more often than not,
they were there because they made money.

As one famous software engineer once said, "'Legacy code' often differs from
its suggested alternative by actually working and scaling."

NASA was reusing code written from the 70's all the way up to 2011! Surely
there is something in this wonderful land of legacy code that is worth saving?
Or how about our operating systems? Full of wonderfully working legacy
software that might just need a touch of love, rather than the usual thrashing
of "how stupid those other devs were" and a total rewrite, which is what
usually happens sadly.

In any case, I think another poster may have touched on it, I think we as
engineers should try to refrain from flippantly labeling anything that is
essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on
the organization) as the pejorative form of "legacy software", and just call
it what it is -- bad software, some of which may also be legacy to your
organization. But the conflation of the two terms is not helpful and adding to
the confusion.

~~~
jacquesm
I've worked on old but very well maintained code that could easily go another
two decades or more. Probably the original writers have long departed this
world. But what they put together was put together with either incredible
forethought or impeccably kept up-to-date. It was hard to tell which because
this stuff was built before the age of version control, which gives you a bit
of an idea how old it was. I would consider that 'mature' code, but not
necessarily legacy.

Legacy code to me is code that has become hard or even impossible to maintain.
Code that people avoid working on, not because it works, but _because they are
afraid of it_.

Sure there are still lessons to be learned from such code, and you will learn
those lessons the hard way if you have the temerity to mess with it. But every
now and then someone is tasked with fixing a bug or adding a feature that can
no longer be avoided and the send-offs are comparable to talking for the last
time to people that are about to descend into a mine or something to that
effect. Everybody knows there is a good chance we won't be seeing them again
for the near future, if the axe of demotivation doesn't cull them from our
ranks.

------
tboyd47
> Code review at the end of the task.

This is something I still struggle with. I think it's a result of an open
source tool (GitHub) bringing bits of culture along with it.

In open source world, all contributions are entirely voluntary, and most
follow the Benevolent Dictator For Life form of governance. So you do a bunch
of work, and you submit a polite request for the BDFL to pull your work into
the project. He or she may decline your Pull Request, request a long list of
changes, or just wait ten years to give any response at all.

In a business setting with hourly pay, deadlines, and co-workers chosen for
you, not by you, it makes less sense. People tend to wait until the last
minute to give or request feedback which leads to a lot of thrown-away work.
Unfortunately, willingness to throw away work becomes a mark of pride at some
places. Maybe enterprise projects need some kind of "managed push" system
instead of a "pull request" system.

Edit: "Unfortunately, willingness to throw away work becomes a mark of pride
at some places." to elaborate, the thing that makes this unfortunate is that
the person assumes that throwing away work is necessary for code quality to
stay high. By requesting feedback at intervals (which is what the author of
the article recommended), you can avoid throwing away work without sacrificing
quality.

~~~
hawski
What I don't like in "commercial" code reviews is that most reported issues
are there just to fill space. It's busy work. There is this formal comment
system. So instead of fixing this typo in a code comment directly reviewer
writes a comment. Code style issues that arise, because of absence of a tool
like go-fmt also warrant a comment. That's sad.

There are meaningful comments, but usually people have to fill their review
quota.

Lowest hanging fruit should be just an in-place edit that would be
automatically retested and that a reviewee can easily take as a patch and
check himself. Instead of the back and forth bullshit.

It's a bit funny that placing a red herring comment that anyone can safely
comment on makes the workflow faster. It's like this story about an artist who
would place something ridiculous so when the time comes the CEO would just
say: "It's good, just remove the thing".

~~~
dionidium
Part of this process, especially for new team members or junior devs, is to
signal that, yes, we take typos (and formatting, and proper grammar, and the
style guide, etc) seriously. I could fix this myself, but I shouldn't need to.
We all make mistakes, but too many "small" mistakes is an indication of
sloppiness. Is this actually a mistake? Or were you just being lazy?

~~~
somethingsimple
Agreed. In my team I am known for being extremely meticulous about this, and
some people don’t like it. If I see one or two typos or spacing issues, I
understand that’s an honest mistake. But if I see typos, spacing issues, bad
indentation, bad naming, etc. all over your diff, I can’t help but think
you’re sloppy. If you don’t care about the little things like properly
formatted code, I have a hard time believing you care about the big things
like error checking and proper test coverage.

~~~
Clubber
A code formatter will save you tons and tons of man hours.

------
navium
Quality means doing it right when no one is looking. - Henry Ford

~~~
marmaduke
A clever quote saves us from having to think!

(paraphrased from some original quote I can't remember)

~~~
jacquesm
Yes, but in this case someone else did the thinking for you and it is actually
pretty accurate. If the only time you care about quality is when you are being
checked, audited or supervised then it will not work.

Quality needs to be infused all across the board and needs to be reinforced
from the management downwards throughout the whole organization, not just in
the quality control department.

So Ford was definitely on to something and beat mr. Demming by a couple of
decades on that particular insight. It's no surprise that both of them had a
lot of these insights in the automotive industry to begin with, where
warranties can very rapidly eat up the profit margin on the sale.

~~~
marmaduke
isn’t this like saying quality code is code that is correct without unit
tests? They seem unrelated

~~~
flynnieous
They are related in that quality code is code that is both correct now and can
easily be made correct when things change--and things always change. Unit
tests are what enable correctness in the future.

------
trevyn
I’ve often wondered about a twisted form of asynchronous “pair” programming:
One person codes quickly, creating mediocre code that achieves the goals, the
other person cleans the code up and modularizes it.

I’m drawn to this because they are two different mindsets that achieve
somewhat conflicting goals, and the tasks can be separated with minimal
communication overhead.

Thoughts?

~~~
gurkendoktor
I just left a project after I was unable to make peace with being the cleanup
guy for an endless, never-improving stream of mediocre code. I am convinced
that it's faster to write solid code in the first place.

Once there are two or more interacting layers of code, it gets really hard for
the refactoring to catch up. If you fix a bug in a basic layer, the leaves of
the codebase break. If you fix a bug in the leaves, you never get to refactor
the core. If you want to stop the world and refactor everything at once, you
get in the way of your quicker counterpart.

Or think of a multithreaded codebase without any synchronization. It
definitely works well enough for demoing an "almost finished" product, but
cleaning it up requires a lot of time and can introduce temporary regressions
(deadlocks) that are worse than the bugs that the cleanup is supposed to solve
(very spurious data corruption). It's a bit like the bullshit asymmetry:

[https://twitter.com/ziobrando/status/289635060758507521](https://twitter.com/ziobrando/status/289635060758507521)

Ruby on Rails (from the OP) makes it easy to build many kinds of maintenance
deathtraps.

------
taeric
The largest burden to raising code quality I have ever seen is the conflicting
burden of maintaining product quality.

That is to say, many of the loudest proponents of code quality are the first
to completely disregard the customer quality points in the product.

Yes, there are fun meta arguments about how higher quality code can let you
deliver faster. Nobody is going to wait for you to get to that point, though.
You have actual users and customers today. Their problem is not the code's
intrinsic quality. Instead, they are trying to use the product. If you can't
tie their concerns to visible metrics that you can move more effectively than
someone else, then you are likely just yelling at your peers. Not helping your
customers.

And please, do not make the mistake of thinking you can push massive changes
without breaking things. You will cause regressions. Period. If the changes
are truly needed, you will make up for them with more rapid progress
afterwards. Don't punish your users, but don't lie to them either. Respond and
get so that you can measure your impact before they contact you about it.
Reach out, apologize and make right.

------
bethly
I've had business people tell me I should stop writing tests so I could go
faster, even when I'm producing significantly more features than the
developers around me who don't write tests. Once you get good at testing,
writing code with tests is faster than writing code without tests: the
challenge is the four to six year learning curve to get there.

I think we just need to stop telling people that code without tests is an
option. It is an integral part of being a software developer, not a nice-to-
have afterthought.

~~~
D-Coder
"I've had business people tell me I should stop writing tests so I could go
faster"

Maybe tell them that double-entry bookkeeping doubles their workload and they
could go faster with single-entry bookkeeping.

------
ryanmarsh
I am a Dev Coach. This means companies hire me to pair program with their
developers and help them focus on "technical excellence" which is manager
speak for "code quality".

Here's what I've found:

\- Most companies _don 't actually care_ about code quality. This is
especially true for the ones that hire me. The managers that bring me in would
much rather play-act than make the systemic changes required for their teams
to operate with improving quality.

\- There are systemic challenges to code quality in these environments. Namely
hiring practices, performance evaluation, and priorities (budget/timeline).
Obvious.

\- Nobody can explain the benefit of code quality in terms persuasively enough
to managers that they will accept the cost. I've never seen it done. It must
come from somewhere else. This is why companies with more technical people in
positions of leadership tend to have this problem less IME. Frankly I think
this is why we use words like "technical debt" either that or it's a
tautology. There's an irrational lack of discipline in this area akin to
credit card debt.

\- Furthermore, software itself does not matter to these companies.

That last one is the most important and it is not meant to be normative. I'm
not saying software is not of actual importance. I'm saying it is not treated
in the company with any importance. Software development is viewed as a
necessary evil, not as an opportunity for competitive advantage.

The difference between my clients who view software as a necessary evil vs. a
competitive advantage cannot be understated. It is immense. Often these
companies with different perspectives are competitors in the same industry!
You can guess which ones are growing happily and which ones are struggling to
cope with changes to their business.

There are companies where the ratio of "business" people to IT is 1:3 and they
balk when you tell them they're essentially a software company.

 _" No, we're a mortgage company."_

Ok how's that working out?

What I've decided is to start doing a better assessment up front as to the
actual priorities and perspective within these companies when choosing a
client. There are companies where the light bulb is coming on and it can be a
blast to work with them. In the current climate I would advise everyone to
just flat out avoid companies that don't see themselves as tech companies.
Work for companies that see themselves as tech companies or are seriously
trying to change that perception internally. You can find companies like this
in all industries. You might be surprised.

~~~
user5994461
Give some names. That will tip out what stocks to buy long term and what not.

I personally found that calling oneself a tech company is not a good predictor
for good practices. Everything call themselves a tech company nowadays.

You should certainly assess what kind of clients you're facing to adjust your
recommendations. However, I don't think that the work environment matters as a
short term consultant, whoever pays on time and has the biggest pocket is a
good client.

------
leibnizwasright
In many companies I worked that were like this, other developers also wanted
to fix these problems. So, talking with them is also a good start I would say,
if you get get one more colleague to work kind of right from beginning is a
nice start too. Normally, QAs and test automation engineers will be all for
improve the situation. Being a bit more vocal on these problems, but it is
important to choose what should be the 1st problem to be tackled.

------
oldandtired
Code quality depends on you. If you are maintaining the system then for your
own sanity, clean it where you can. If you are writing the system for someone
else to maintain, clean it where you can, because you will probably be the
poor sod who will have to maintain it later on.

If you can't clean it now, write down everything you know about the system,
all those little annoying assumptions that nobody else has documented. Do this
for your own sanity.

Don't be afraid to rebuild something if that will get you out of a bind. It
will be for your own sanity to do so.

The pragmatics of cleaning up code is for your own sanity, unless you intend
to leave in the near future. In that situation, it will be someone else's
problem. But remember that in your next job, you'll become the someone else.

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

~~~
jrochkind1
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've seen is characterized by lack of transparency and truth
internally -- nobody knows what's really going on, so there's nothing to do
but political games. I think that lack of internal honesty is a cause, not
just a symptom. So your workaround to let you do quality work despite being in
a dysfunctional organization, misleading your peers and/or
managers/administrators, makes the organization's dysfunction even worse,
making it even harder to do quality work. In another kind of vicious cycle.

After a bunch of years of programming professionally, I've come to the
conclusion that my job includes not just trying to make the code better, but
trying to make the organization better too. The same way you've got to 'fight'
for quality code, you've got to 'fight' for healthy (honest and respectful)
organizational culture.

There are some (many) places that are so dysfunctional that they seem
hopeless, and maybe you can't easily leave and find other employment. You've
got to do what you've got to do to stay sane (and keep your mind from dying)
and I don't fault people for their coping strategies in such an organization,
but I think misleading/lying (which is really just a kind of 'political' game
of it's own) to give you space for code quality is likely to lead into a
vicious cycle of descending badness all around, not ultimately leading to
increased job satisfaction.

~~~
noxToken
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?

~~~
jrochkind1
I have not completely figured out what to do, but I'll say that if you leave
because the organization is not interested in producing quality code and you
don't want to work for such an organization, and they were unwilling to give
you time (ie money) to produce quality and maintainable code -- the problems
they have maintaining the code after you leave, having made efforts to
educate/convince them of this fact and failing, _are not your fault_ and _not
your problem_.

The tacit knowledge you take with you, when they were not willing to give you
enough time to share/document this knowledge, or produce code that was more
transparent, despite your efforts to tell them the consequences -- are _not_
your problem. Don't get Stockholm syndrome.

I realized at one job that I kept busting my ass to cover up for management
failures (that I wouldn't get credit for saving them from)... they would NEVER
LEARN. I was enabling terrible management and a toxic environment. They didn't
even _realize_ I was saving them from themselves (and if I'm wrong and they
were right and I wasn't, all the more fine it was for me to leave).

~~~
justin_oaks
I just left a job where I knew that management would never learn. That was my
primary reason for leaving. All other problems could have been fixed IF they
would listen to the employees and/or learn from their own mistakes.

Alas, it was not meant to be. I feel like I was an enabler because there were
a lot of things that I held together despite not receiving any support from
management.

------
logfromblammo
You build version 1 to throw away, version 2 to be upgraded, and version 3 to
be maintained.

If you never get to version 3, you never get the opportunity to worry about
code quality.

~~~
justin_oaks
Every company I've worked at will ship version 1 to production and proceed to
build on top of version 1 forever. Of course, by version 1 I mean "the proof
of concept I showed someone else".

~~~
logfromblammo
A log can dream, can't it?

It's the classic bait-and-switch of corporate development. They get you in the
door by pretending they have a rational process, and wait until you're
invested before dropping the facade.

I, too, have never worked for a company that ever considered retiring software
ahead of immediate necessity. Generally, it's always "we don't have time to do
it right in the first place, because we're too busy fixing all the stuff that
is broken right now."

------
jimjimjim
i used to be a software archeologist at a previous job. dig a small hole and
uncover the artifacts and ruins of a previous project civilization.

please, for humanity, write documentation. even better if it's after the code
is written. why does the payments-smart-broker have a direct connection to the
translations database if it doesn't have a ui?

------
mempko
It doesn't matter how pretty the code is if it does the wrong thing. Software
quality is the interface , not the 'code quality'. Usually code quality helps
build higher quality software, but it isn't sufficient.

------
Ocerge
I hit almost this exact situation at my last gig. It came down to one of two
things: was I okay with complete job security while being completely bored and
apathetic all day, or would I take a bit of a leap of faith if it meant
getting out of a rut? I chose the latter and it worked out. Maybe if I was a
higher-up I would have tried to fix things, but it wasn't really my
responsibility at the time. I'm not completely absolved; I could have tried
harder to institute things like PRs and linters, but my give-a-fuck was far
below the threshold it would have taken for me to really take action.

------
sseth
When code quality is hard to enforce, one approach is to at least ensure that
the design of public APIs, and boundaries between components reaches some
level of quality. This is usually a smaller surface to monitor than the entire
code base, and it allows islands of good quality to emerge. Good boundaries
also will allow for easier refactoring over time of the really bad code.

------
realworldview
Ahhh, life. If only everything were perfect. Keep pushing but don’t be
surprised by the pushback and despondency. But keep pushing, for yourself, and
others who want to care.

------
bryansum
One huge problem is that there’s no context-indepedent definition of quality
code, and criticisms often suffer from hindsight bias.

~~~
bethly
This is why Sarah Mei's idea of Livable Code is so exciting to me: it talks
about context-dependent quality code, and lets us talk about developing the
context needed to move our definition of "quality code" to a more
effective/more reliable/faster/faster-to-develop place.

------
myf01d
This is the second post from this website to get upvoted to the frontpage
within 48 hours. I hope this is natural.

------
jbrooksuk
This is why I’m keen on automating code standards/quality away. We’ve recently
launched JS, CSS and Vue.js support in
[https://StyleCI.io](https://StyleCI.io) to help more developers standardise
their code.

