Hacker News Reader

Comment by ManlyBread | Hacker News Reader

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.

View on HN

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.

Put another way:

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

-Ze Frank

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

This is a very good, professional response.

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.

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.

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.

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

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.

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.

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.

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

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

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

I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity."

I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE.

It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change."

[0] https://en.wikipedia.org/wiki/Codependency

At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.

This is terrible advice. Do not go to legal for this, ever. This is putting yourself and the company in a very bad position.

Fix the vulnerability if you can. Help junior developers understand common issues if you can. Then move on to the next job with better practices.

> but some of these things are very serious security vulnerabilities.

That's a very good reason to bring in your Security Officer or a similar compliance officer; its probably not a good reason to go straight from dev to Legal.

Don't stress about code quality.

Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place.

PS: This is not giving up, it's about getting even better by becoming ever more flexible.

this is very selfish, unless you're the only developer in your shop.

whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU

Not just your coworkers today, "future you" as well.

I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.

If it worked for a year without bugs, then it's not garbage.

Did it work? Can you read and understand it? Then it has value.

Unless it had no users or it was so much garbage that nobody reported any bug.

That would mean it did not work.

PS: The goal of Windows is not to create an OS the goal of Windows is to make Microsoft money.

Don't assume I am talking about personal ROI. Team ROI is critical. Seeing a feature early so we can decide if the goal needs to be changed it valuable. Clean code that's going to be deleted tomorrow is not.

The 3rd time you touch a function is often a great time to make it awesome. However, a lot of code never reaches production and maintainability is more of an issue for code that survives.

I don't think the parent was talking about writing bad code. I think he/she was saying not to stress about writing good code too much. Those are different things.

There is a lot of binary discussion here that treats code as either clean or not. Of course, it's always somewhere in the middle.

Finding the right line in the sand for your current job is an art. There is ALWAYS more you can do, and being smartly-selfish is inevitable.

This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth

It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.

I've seen a lot of well-intentioned code refactoring that made the code objectively worse. Refactoring well takes a pretty seasoned programmer to do it.

Reply on news.ycombinator.com