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

[s73v3r_]

Better advice: Go to where they actually care about what you're doing, if you can. Otherwise, put effort into what you're doing, but don't go overboard, and absolutely never work overtime.

[scruple]

Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount of money on the line that drives these decisions. And, so it goes, "get it done and ship it yesterday" is the commonality that I see.

That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.

[vvanders]

I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you.

The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit.

The former usually means that you'll try and budget in time after the crisis to fix it up, the latter tends to spiral into a complete mess that no one wants to touch after a certain amount of time has passed.

[bethly]

Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.

[vvanders]

Yeah, there's a natural tension in this. I know I tend to wander towards the "ship it" category but yet I've found my best work was when I was paired with someone on the "correctness" side of the equation.

It forces a constant re-evaluation of your methods and reasoning on both sides which leads to something even better than the two individual approaches.

[therealdrag0]

Not sure why there's a hard-no on working overtime. Not everyone finds value or fulfillment in the same way or has the same goals.

My cousin just went from being an intern at Tesla to a FTE. This group change entailed going from 11-12 hour days to 9-10 hour days. It's crazy and maybe not for everyone but he's happy there.

I work at a more chill company, but sometimes there's something I want to do on the company code base that is not asked for by any stakeholders. I'm happy to occasionally put in an extra 10% to do something that scratches my own itch. I don't see much difference between this and someone who goes home and works in their garden or plays with Arduino or tinkers on an old car.

[AnimalMuppet]

Working overtime? It happens. I accept it as part of the job, as long as it's rare.

Working overtime to clean up other peoples' mess that nobody else cares about cleaning up? Hard no.

If it floats your boat, if it's a hobby to you, if you want to spend your free time on it, then sure, knock yourself out. Have fun. Feeling like you have to? No.

[blechinger]

I get where you're coming from. I just did this the other day (worked through the night on something for someone else over the weekend) but I may not have if I knew someone was going to come behind me and blow it away.

Maybe what I learned from it alone would be worth the effort. Tough to say.

[s73v3r_]

All that work would still be there in the morning, or on Monday. And you'd be rested up, and far less likely to make mistakes.

[s73v3r_]

If they clearly don't care, then working overtime is not going to change that, and it's just going to make things much more depressing.

This is on top of the "never work for free" rule. All that does is bring down the value and respect of our entire industry.

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

[adrianratnapala]

Yes it is good to understand people and the business, but you are also hinting that much of the bad code around the place is some kind of big-picture smart optimum of technical debt. vs. development velocity.

But this is unlikely if you stop to think about how humans behave. Who in an organisation has an incentive to find such an optimum? Shareholders and the board maybe; but they can only drive things by rewarding and punishing middle-level individuals. And they can only reward impact that they can see. Thus the incentives are to create visible impact which can be spun as a net gain. If that creates technical debt, then that is somebody else's problem.

[sanderjd]

Yep, this is difficult, but I think it is the correct approach. To follow on: if you do this successfully and you also demonstrate technical value to the organization, you are very likely to find yourself with enough credibility to successfully advocate for (or lead) efforts toward better engineering practices.

If you do all this, and never gain that credibility, possibly due to problematic individuals at the higher levels of the organization (which you can't control), then it's probably time to move on.

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

[drvdevd]

Especially in a startup, but obviously in established companies as well, this will give you an idea of where it’s all headed.

If you’re in a place that’s reliant on good code (and good execution strategies) to exist, and the other people don’t or won’t or can’t really grasp the magnitude of what good code means to the company - leave.

[mistermann]

> At the end of the day the goal is not to produce clean code. It's to make your company successful.

An even more accurate description: don't assume anything, determine what the goals of the power player employees at the company are, and follow their lead. Assumptions of doing a good job, helping the business, fulfilling the mission statement all seem like reasonable goals, but assuming you are working in a reasonable organization is not always a safe one. Sometimes, the whole thing is mostly smoke and mirrors, and someone coming along with the aim of doing a good job will become very unpopular.

If you happen to find yourself in one of these places, just imagine yourself on the set of a TV series about an IT department, say all the right things, and you might very well be able to get paid to play around with things that interest you 90% of the time while keeping up appearances with your other 10%. Be mindful of what this can do to your resume and skillset, but as long as you're making productive use of your time learning new technology, you can typically lie about what you did at your last job and most interviewers won't have a clue anyways.

[laythea]

This is a very good, professional response.

[Balgair]

Put another way:

"If it's just a stepping stone, then be fascinated by the shape of the stone"

-Ze Frank

[jogjayr]

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

That's a tiring way to live life too. If you're surrounded by villains, you should try to leave and go to a place where doing the right thing is easy. If at all possible.

[mkempe]

Strongly agree. Still, do keep some of your powder dry and look for opportunities to join a better team or company.

An engineer once told me he cried with joy when he saw the interface and used some subsystem I had written a year earlier (in C, for an embedded system). So, I encourage you to write such great, beautiful code that other engineers will cry with joy when they behold and maintain it.

[space_fountain]

I definitely do the best I can, but as someone sort of in this position I worry that I'm becoming a worse programmer for it.

I'm junior enough that I often don't know what to do. I've never gotten really good at full unit testing for example. I really do think in situations like this my best bet is trying to find somewhere where they follow better practices.

[zamber]

Imitation is the best form of flattery but you can also be proactive in your learning how to write better. Read code that's open-source and solves similar issues for a similar case in the same tech stack. Understand the architecture and conventions. Understand where the codebase has areas for improvement.

Before you learn about types of hammers and nails learn when to use which one.

The problem with more senior people is that they can lack the time and motivation to teach you so until you don't own the problem yourself pushing it to "ppl don't want to teach me :(" will not do anything.

Also, practice makes perfect and good coding practices tend to be somewhat universal.

[lamby]

A friend once wrote on Reddit:

> High standards for workmanship and worker safety are luxuries, but even some people who have the benefit of access to good training and safe workplaces don't take advantage of them. You shouldn't be ashamed of striving for the highest quality work you can do — instead, be thankful that you know what to strive for, and pass on your craftsmanship to anyone who is willing to learn.

http://www.reddit.com/r/Welding/comments/1z9oc1/serious_how_...

[SaltyBackendGuy]

I wish I could upvote this more than once. Reminds me of one of my old Army SSG. Simply, do the right thing.

[iamcasen]

That's all well and good, but what if delivering good code actually necessitates a pretty large shift in the codebase? Usually that requires buy-in from teammates because it will take substantially longer.

Almost always the answer will be no. So you're forced in a way to ship bad code.