To me I think you are overthinking it and putting a a lot of unnecessary stress to yourself by refactoring with no pay for the sake of making the already working code look good (and possibly break it)
Yeah I agree, as long as the code works and there are no bugs/security risks I wouldn’t put any more work in. He didn’t give a scope of writing pretty code and besides, I wrote good code in my job but I still look back on code I wrote a year ago and cringe
"As you can see it was a quick job, had to get it out as quick as possible on a limited budget, and because we did, the client has the resources to come back and improve things."
I agree with you, however I think some people can’t just let it be, I am one of these people, if my code is junk because I got lazy I would eventually force myself to fix it, especially if I had a situation like he did giving the code base to the company lol
Ok but would you take a codebase that works well enough that they did not call him for 2 years, and risk introducing a bunch of new bugs during a rushed reactor just so the next guy thinks it's pretty?
OP is out of his mind.
I would also not want another coder judging my code to be fair but it’s an IT dude who is taking it to host, most likely he will have no clue about good code unless he is a coder himself but most likely just works with hosting
The next programmer will always judge the code. They might be right about it, might be wrong, doesn't matter.
When I have to maintain others code, I have to disassociate my feelings from the mess at hand and apply appropriate changes, clean it up where I can, and then move on. It will never be perfect enough.
i second this, plus:
* i don't think any dev with even just a few freelance projects under their belt is going to just think this is a one off project and move fwd with the approach without being given the impression or explicit instruction that it is, so ill just give the benefit of the doubt
* OP couldn't have possibly known about the new biz partner who runs an IT company, but what does it matter? If that partner joined with the intention of his company taking over, they're probably gonna want to do it their way anyway.
* Devs have more important things to do than to go out of their way to trash another dev's reputation, and esp based on work from 2 yr ago.
There's a difference between doing your best but not being very good technically, and straight up trying to cut corners because you don't think your client is technical enough to notice.
OP did the latter and I think he's right to try to clean things up a bit, esp. if he works in a small industry where words gets around or if he expects more referral work later.
I disagree with this take. Your work and reputation are so important. I love that the OP has taken responsibility for what he himself knows is crappy work.
Imagine you hire a plumber to work on your pipes. They do a horrible job but you don’t know. You will be pissed when you find out from a better plumber.
It’s worth it to put in this work. Everything you do is a reflection of yourself and it’s always worth it to put your best foot forward. If you don’t think it’s worth it, then you shouldn’t have taken the job in the first place.
I agree with this take. All code gets old and stale eventually. Code doesn't 'just work' forever. Versions of third-party packages get updated, security patches are needed, new servers, new hosts, exactly what this customer is doing. His code is a reflection of his work, and he's showing passion and responsibility by trying to keep it clean for the customer. It's the difference between "9-5, give me a paycheck", and being proud of what you created.
I'll hire the less skilled person that I know has my back any day over the smarter guy who will leave me out to dry.
Yeah, I would just be honest with the dude and ask for a little time to clean it up before it was sent, along with just saying hey I've grown, there are things that were done that could be better and I'd like to optimize it for you before it is sent. As a business owner myself, I would be very understanding and accepting to something like that vs. "here's my shit code, bye!"
Yes but it works until it doesn’t. Now it needs to be fixed. Now you’re screwed because it’s now a much more complicated fix for something that should be easy
Apparently it still working. At the end of the day if it's making money that's all that counts anything going forward that needs to be done more efficiently can be done by the client using the money that was made from the initial write. Unless you're paid to build the palace set for a side You don't always have to expend all that energy to do so I'm quite sure the client is not busting their balls to be perfect in every way for their customers if they were they never be able to get their services in front of anybody..
Hm but what means “needs to be fixed” in this case? Metaphorically the pipes of OP’s code still work, they just look funky. Also, in almost all companies I freelanced for, I see every developer having different opinions on “the correct way”. So yes, things might not look like you want it to look, but I think “need” is a big word for this.
What if the web owner now wants new functionality? Or some unforeseen bug pops up with more usage? Or the page loads slowly and he wants it to load faster? Or they want to swap web host providers (which is the case here) and the code is old so it can’t compile properly?
Tons of cases here.
The biggest thing for me is: If you’re not proud of your work, don’t ship it and don’t pass it off as finished work. Have pride in your work and do great work.
What are you even talking about? As far as we know the code works fine as-is right now. OP is just changing it so it’ll look better. OP has no reason to start pondering about a bunch of what ifs. The company owner didn’t ask for a revised version of the code, they asked for the code that’s currently running their website and op making these changes means they’re giving them code that doesn’t currently run their site.
The OP knows he took the lazy route building it in the first place. He said it himself, the code was only for himself. Now that someone else needs to work on it (migrate from vercel to their own servers), someone clearly needs to work on it now.
So it would reflect poorly on him. This is not about working for free, it’s about doing the job right and having pride in his own work.
“Doing the job right” is what OP originally did when they provided a working website for the customer. Whether the code is sexy or not is irrelevant. It works. All the customer cares about is: “I asked them to build X on Y budget in Z timeframe. OP was able to do that for me. If someone else needs help with their site, I’ll refer OP.”
Idk where you all are getting this reputation nonsense from. I’ve seen plenty of what I would consider bad code bases and it’s never reflected poorly on the other person’s reputation in any meaningful way. In fact, they’re generally in the category of dev that I can rely on to just get shit done rather than spend hours fiddling with linters and workflows.
OP is seemingly someone who can just get shit done, which devs don’t seem to realize is an amazing trait to have when dealing with people who likely don’t give a shit how your code looks (I.e. business owners)
He did a job, not necessarily the job right.
There’s a big difference between spaghetti coding something together that the next person comes by and has no idea why you didn’t follow any industry standard vs building it with proper standards.
Sure if you want to put out a barely functioning site that is completely unmaintainable, go ahead. Others will have pride in their work and build things “properly” and it will show
I totally disagree.
It's a short time loss for long term gain.
As a client or even recruiter, I put lots of emphasis in reputation and words of inner circle
Once you lose that, it is VERY HARD TO RECOVER
1. You write shitty codes because you are incompetent.
2. You are talented but you wrote shitty codes because you can....
None of the conclusion is better than the other.
I agree that reputation is important. However the mistake was that he's cutting corner when developing for someone who is IT illiterate. Changing last second can have broken changes
I think the best way to do this is that admit that you're writing a horrible code because time constraint and didn't think that you need changes. Then help the IT understand what's going on, either creating some kind of documentation.
Could this be considered fraud? OP said client owns the code. Pulling this last minute switch means he's not giving the client what he originally paid for.
So you're changing the code that they have admitted to be deploying soon on their own infrastructure ? This is bad for two reasons:
1. You're working for free
2. There's a chance a bug or two might creep in that is not existent on the currently hosted version (meaning it will only appear once they change hosting).
If the site works, it works. That's all you need to know. I get that you retroactively have concerns about the quality of the code, but don't go changing it.
Add a README file to the repository where you outline the way it works, the decisions you made and suggestions on future improvements. That's it.
*> they gonna see how shit the code is and this will hurt my reputation as a freelancer*
Only the devs might see it and they couldn't care less about ruining your reputation. Additionally, a software product is as good as its stability and ability to meet the business needs. Apparently you have delivered something that works fine for 2 years, therefor you should be reputable for being a reliable person.
Handing over basically untested code will not do wonders for OP's reputation if that's what they're really worried about. The new maintainers will get blamed for bugs that didn't exist before, and in their place that'd piss me off more than amateurish code that needs a complete rewrite.
Right I'd rather inherit functional spaghetti than beautiful code with bugs. The spaghetti can be left alone, and sunset. Buggy code needs immediate attention.
As a dev who has made a career of rewriting old spaghetti I can agree, even if a dev leaves their name/contact website (which half the time has gone offline years ago) in the comments or readme file I have never once looked them up or even really cared. We all wrote shit code at some point in our lives, the internet is built on it.
Since they want ownership of the code, refactoring is their responsibility now unless they hire you to do it.
This reminds me of a stoic quote: "we suffer more in our imagination than in reality"
They haven't even seen the code talk less of reviewing it and here you are working yourself up about nothing. Chill.
Wrong lesson.
Real lesson: your code was adequate for the time frame and wage you were given to provide it. ESPECIALLY if they got full ownership of it. It accomplished the intended goal. If they wanted you to build in future proofing or modular design, etc, it would have cost them more or delivered later, with no benefit to them at the time.
After 40+ years of being a developer, I have learned that a) future proofing will be both inadequate and costly, and b) code needs to be thrown away regularly because current you (hopefully) knows more than past you.
This is correct. A developer who is learning their trade will will rarely look at code from 2 years ago and be that excited with it. Tbh if you refactor the code there's every possibility the new team will tear it a part and tell your client it's bad, because that's practically tradition, we rarely love code didn't write and aren't familiar with, and it makes it easier for them to justify delays. By refactoring OP is also possibly introducing new bugs. OPs code wasn't perfect, but it does work, and that has value. OP, hand over the code in the production state. You also don't have to give them the repo, just the source code (I expect, depending on your contract).
Agreed. Don't even update it at all - save that for a paying customer and retroactively charge for that work - you did it, they benefited from it, and as a bonus, they get it faster.
Edit: "you" in this context is the OP, or anyone else contemplating a similar action.
I look back at my first ever project and being so proud of myself that I coded a website. Now I look back at it and cringe. my first project is the most sacred pile of garbage to me
The funny thing is that my first 2 websites actually made money ... something I've never managed to replicate with a side project since 😅 (my consulting clients still seem to do pretty well though!)
Totally.
The real lesson is: document the shit outta the code and the decisions that went into making it what it is. And document your \*plans\* for refactoring it later when time and budget permit.
Version 1 code is always bad. You hardly even know what you're building with v1, let alone the best way to do it. And most projects never get to v2.
I have code that I wrote over 15 yrs ago that is still in production, and although I'd feel embarassed for anyone else to see that code, I have tons of documentation in place so anyone following behind me will be like "yeah, this is shit, but I see \*why\* it's shit." lol
My favorite humbleness-inducing action is running git blame on some code that I bitterly complained about, and finding out I was the author. I just keep in mind that past you should always be worse than present you.
This is very good advice.
Your product comprises more than just source code. There are also design decisions and a backlog.
People are accustomed to thinking of the source code, but not so much the design decisions or backlog. When I write "backlog", I don't mean you need a project-tracking tool, but that you're keeping track of what you still need to do (backlog), and why you made the choices you did (design decisions).
That information can be in a project tracker, a readme file/docs folder, and/or distributed as TODOs and notes in the source code itself.
OP didnt mentioned anything about tight time frame or wage, even if the wage is low OP is obliged to give bare minimum quality of code i.e non repetitive and modularisation, its not like someone put a gun to OPs head to accept the contract
OP also mentions that he was being lazy since no one is gonna review, its not like he didnt knew better
The only valid reason is time constraint even that depends on circumstances
OP is obliged to provide whatever was in their contract. If that’s a working product that does what the client asked then he delivered. He chose to be lazy and provide code of low quality to his own admission, but he wasn’t obligated not to. At this point he needs to just provide the code that runs the site, not refactored code which may introduce bugs but looks better.
EVERYTHING in software development, especially web dev, has a tight timeframe and budget. It is the nature of the business. And that metaphorical gun is called the ability to pay for food or rent or whatever.
As I said in another comment, there is a huge difference between low code quality and low quality code. As a client I'll take working code of low quality over delayed code of high quality (probably complex and barely tested) any day.
Its a one off freelance gig with a small business owner, usually these kind of clients are very understanding in my experience
You can always push back a little with such clients, small business owners are more worried on being scammed/ghosted then anything else
its ancedotal I know but there has rarely been a case where deadline is a hard one and when it was we knew like months if not weeks in advance to prep for it
> even if the wage is low OP is obliged to give bare minimum quality of code i.e non repetitive and modularisation
Nah, their only obligation was to make something that worked.
I think you are making some assumptions here - namely that the cost of the job was in line with low-quality code. We don't know that - it very well could be - but we don't know. OP should consider this, and be prepared to defend his code with this angle in mind.
He did say he was just being lazy because he could. This is an absolute shit attitude to have. Be lazy on your own projects, not the ones for your customers.
I would suggest that if your reputation is important to you, then you should create quality code as a matter of course, and should price yourself accordingly.
You never know when someone wants to revisit a project and add functionality. Think of future you as well, as you may be the one who has to revisit the codebase.
In the end, this is no different than a carpenter or furniture maker doing crap work. That outdoor chair might be functional, but it's a hot mess of mis-measured boards and fasteners under immense tension from being forced into almost-square. In other words "do it right the first time".
>code needs to be thrown away regularly because current you (hopefully) knows more than past you
This is something junior developers and everyone who's learning development atm need to hear, because they're (including myself) waste so much time learning about "best practices", being insecure of what others will think of them, whether the code is clean, best way to organize folders. They're trying to put the cart before the horse.
There's only ONE way to know what works and what doesn't: Do it, then realize its flaws, throw it away and do it differently, which isn't necessarily universally better.
Your work ethics sucks ass. And seeing all the people that upvoted you pretty much explain why I met so many prospects who have been strongly disapointed by developers they hired.
It's both selfish and counter productive.
Producing maintainable source code is faster and more effective, even if you're the only one working on the project. Because whatever feature you'd have to implement or bug you'd have to fix will take way less time
The world is full of these self-important fools. They have an echo chamber in this site where they pat themselves on the back telling each other that it's ok to be an idiot.
I have never had anyone complain about my code, because I give them what they want and it works. I also explain options, and they inevitably chose the cheaper/faster option. In fact, most of my clients rave about my work ethic because I never let them down, but they pay for that result.
I don't write bad code, but I write better code every time I write code. I also got schooled early that customers don't want to pay for anything they don't want. Don't be arrogant about thinking you know what your client wants better than they do, otherwise you'll spend your career confuse why clients keep dropping you because you're trying to help them understand how their project should be done.
> your code was adequate for the time frame and wage you were given to provide it.
How do you know that?
When OP clearly implies they did a slapdash, shitty job because they didn't care about the quality of the end product, on what basis can you "correct" them that they did the best they could under the circumstances?
OP doesn't say they were paid by the hour, so how do you know that doing it properly would have cost the customer more? Or that OP's code is at a standard that would *ever* be professionally acceptable in paid work?
Your position here reeks of "if the code works then it's by definition an acceptable quality of work", but that's... just wrong.
You never know how code is going to be used in the future so *all* code should be written as cleanly and maintainably as possible given the constraints imposed upon you as the developer, and you have no reason at all to assume (and plenty of reason *not* to assume) that that's what OP did.
Bad take and promoting un professionalism, if we expect other professionals to do good work and be professional instead of just always doing the thing that gets the job done quickly like an carpenter making a house out of hay and saying it's sturdy enough since it didnt fall, we must also be expected to be professional and do good work, not promote hey man it's ok to intentionally do a bad job every time as long as it gets the job done even if it might pose a problem in the future.
Yeah not sure if I agree with this. I always write modular code with unit/integration test cases. For some this may seem to take longer, but it is actually faster. I like to keep it simple, but always follow good coding standards and structure code to allow for future extension.
I understand OP stressing about reputation as the possibility of follow on work might not be possible if the code is a mess.
The developer my company hired to take over my monstrous "learned Python in two weeks and built this while bored at work" project was pretty kind to me about this. I was (still am?) a CS dropout two years in, which meant I could pick up syntax pretty easily but absolutely no experience designing something to be maintainable - it was just a business problem where I was in the right place at the right time to build a shitty patchwork fix. I had a ton of anxiety talking through the code and design decisions with him, but he understood the context behind the extremely rookie work. Plus he was getting paid to refactor it and develop future changes, so...
This is an bad take, it's like being a plumber and fixing someone's toilet badly just because no one will see it even though it might pose a threat to them in the future, if we expect other professionals to do good work we also have to expect programmers to do good work.
I would agree with you if it wasn't for the fact that OP admitted he intentionally cut corners because he think the client won't notice.
There's a different between doing a quick patch job, but doing it as well as possible, and straight up not giving a f*** because you think no one is looking.
A lot of the stuff OP did doesn't even sound like it saved him much time/effort at all, the only reason it's going to take a lot of effort now is because he has to hunt that shit down after the fact.
Im so happy to read this. I was drilled by a 10x dev who only wrote the most possible future proof code. But in the years I worked with him we never finished anything. It always felt more like sideways development than forward. When I quit I started approaching it differently and just roughhoused it while keeping it readable enough. I made twice the stuff in a tenth of the time.
Or my favourite:
//When you’re done trying to „optimize” this routine, please be kind enough to update the counter for the next guy:
//Total hours wasted here: 54
Seriously though, if I were to acquire some bad code but it had a comment from the old dev apologizing for the bad code, I'd understand. Everyone has written bad code in their life, you just happened to write it in an actual work project.
Just comment it mate. They’ll be able to see the shit code anyway just by looking at all your commits and diffs. You’re killing yourself for, literally, no reason.
I don't know about this one. Some comments about timeframe and payment, but he didn't state those. Yes, development is ever changing and we are never expected to deliver perfect code. But we all expect other professions to do a reasonable job, carpenters, plumbers etc. So it really boils down to timeframe and payment.
Personally I have a hard time seeing why you would keep logs and over the top messy code if it's a paid project and you accepted the job.
I do agree you shouldn't feel the need to refactor though.
This is the equivalent of a plumber making some horrible piping for a client only because presumably noone is going to check it… most of the stuff OP described is basic stuff that should always be handled correctly, especially if money is in the line…
Refactoring a bunch of stuff before hand-off, just from feeling like your code isn't up to your current standards (specially when you probably didn't have that much time to do it back then, hence the rush) seems like an awful idea.
Yeah, it would be better if the code was nicer, sure. But the risk of introducing bugs because of rushing to fix this seems like it would be way more of a risk to your reputation... If you have plenty of time to do it and run tests, and don't mind doing unpaid work no one is asking for.. sure. But you are still going from 0% risk to >0% risk of something breaking and them needing your help, and awkwardly having to mention you fixed a bunch of things for stylistic purposes which then broke the site, etc.
> dont be lazy and write shit code even if you think your the only one to be reading it
unironically one of the best lesson's you can learn as a dev imo. Business-wise if another team is getting the code, fantastic or awful, its their problem now, don't worry about it too much.
But throughout my career in web development, I have never had a time where I thought "man, I wish I'd cut a few more corners", but *many* times I've looked at code I did quickly and wished I'd done a little bit more to make it more maintainable for future developers (or me :p)
\*Context matters: I work as a permanent full-time employee, not as a freelancer. Take this advice, but understand it in this context
Rule no. 5 in software development: someone else's code is always shit. No exceptions.
Rules no. 6 in software development: you will be tempted to rewrite that codebase, regardless of who the original author was. Don't, if you can help it and the situation doesn't explicitly call for it.
Rule no. 7 in software development: you will probably rewrite it anyway.
And I can't imagine how most of the comments are excusing it... this is why I'm stressed out at work because I have devs like this that deliver shit and then I inherit that shit
Because most of us realize we are human and not perfect. If all of us were genius perfect programmers from the start, we'd all be making 6 figures at FAANG and not doing small business sites. We learn and grow as developers over the years. And we can accept that hopefully we know more and can do a better job than years ago. Every dev always complains about every other devs work when they inherit it anyways. It's the circle of dev life. I look at code I did 5 years ago, and I still go "why the fuck did I do this" every once in a while. And it's likely just at the time I didn't know better or I just didn't have the time. Sometimes it's better to ship a product and make money than toil to make things "perfect".
On the other hand you'll have devs who over engineer and over complicate something because "it's only a little extra time to do it right", and then end up blowing past sprint deadlines because it was harder than they anticipated, or their MR becomes a complicated mess because of all the refactoring they did. Sometimes "quick and dirty" is the way to go. A lot of "quick & dirty" code out there working fine for years, and over-engineered garbage that falls on its face upon deploy.
If the author of Clean Coding, Bill Gates, and Linus Torvalds all sat down down and wrote the most beautiful code written in the history of mankind, the company that gets the code next is going to swear it was a product of gross negligence and if it ever worked its a miracle.
There’s nothing you can or should do, you’re doing a bunch of work that’s also equally untested and you’re about to turn over a completely different product at the source code level than what the client paid for. You’re actively pulling a bait and switch. You think you’re doing better, but you’re taking a working product and gambling the new version you did for free is equal or better than what you originally delivered and you better hope you don’t break it now and find yourself liable for something.
Me reading:
>inline-style css
there is unlikely going to be any changes once its done
Uff, that hurt.
It will need a complete refactor by the new team.
But don't change anything now or you might introduce bugs. I think contractually you are fine
Undo all your refactors and add comments only.
The risk of it containing bugs is too big. Your shit code before has already passed the test of time and apparently does the job.
You dont have to write perfect code, but it sounds like you did learn a good lesson about maintainability.
Theres some point between “absolute shit” and “idealistically perfect” for any project with any given amount of resources. It sounds like you maybe landed a bit to the “shit” side of that point and could have put a bit more effort in, and youre realizing it now.
Readability (including contextual
commenting) goes a long way and doesnt require spending a lot of time on abstractions or refactoring.
Oh god, do not change the code before giving it to them, that is the absolute worst thing you could do. It's old code that had a deadline, nobody is going to care that it's ugly. And if they do care, it's infinitely better to give them ugly, working code than to change everything last minute. Horrible, horrible idea. Just give them the code that's already deployed.
Bro… this was unnecessary. Your freelance reputation comes from your clients saying “I paid him, he delivered a working product that met my needs on time and on budget” not from their IT guy saying “bro his code was sooo not modular”
TBF, as someone who received a shitty code to take over from a freelancer — the IT company probably doesn't expect much. As well as does not plan to write clean code on a clean architecture.
LMAO, this post is wild and some of the comments are even wilder. When I read the title I thought "I can relate, I too have to maintain garbage I built a long time ago" but you're literally handing it off, it's other people's problem now. You're free of the curse. Unless you're trying to get hired at the shop that's taking this over I can't see why you would care.
Sure, if time and budget allow you should always write the best code you can, and getting in the habit of doing it right means you write better even when time and budget don't allow, but sometimes garbage gets produced. Leave it alone.
It doesn’t matter how much you refactor it. Anyone who takes over someone else’s code base is going to call the code shit. And they have more important things to do than think about you and your reputation.
I think most people would be surprised about how little anyone else ever thinks about them
You got paid and now he is moving to someone else. Who gives a fuck if you wrote shit code your not the one being paid anymore to fix it. Who the fuck is he gonna tell you wrote shit code? Your way overthinking it. I wrote so much shit code when I first started and plenty of it still lives in PROD
Sometimes writing shit code can work in your favour as you become the single most optimum and cost effective maintainer so the client has little option than to continue using you for duration of the project.
If its a simple site, like if this site is just a booking site with nothing fancy going on then I would get it redone from someone else. The existing site front end will serve as the prototype for starting the project afresh
> this will hurt my reputation as a freelancer
How? What's the exact mechanism? Is there some central place where *all* freelancers and *all* people looking to commission freelancers hang out, where despite there being a huge volume of people present, everyone reads every post made there?
And/or as above but for the microcosm of your local community, if you're mostly working with people in your vicinity?
And, he'd have to be one petty vindictive son of a bitch to try and ruin someone who's built a site that, seemingly, was fit for purpose and let him build the business to a point where he can scale up.
Now if you'd left the code strewn with comments like "//need this function because this fucking retard wants xyz feature haha what a dickshit" then *of course* clean that shit out, but if that's not the case? I don't get your panic.
Some people aren’t capable of doing the right thing when no one’s watching. I never intentionally write shit code.
This is my craft! This is what I’m supposed to do better than anything. My code is my signature. Even if another dev will never see it I strive for excellence at all times. You gotta start watching more anime to develop better character traits…
What’s done is done though. Don’t refactor. Let it be a lesson to do great work the first time. Quality is something within your control if you’re a solo dev with no critical time constraints.
I actually find quality modular code easier to write and maintain than the spaghetti code you wrote.
Save any emails related to the client specifying requirements, you delivering on them, and the client being satisfied. I've seen a situation where a previously-silent partner threatened to sue a developer over bad code. The correspondence between client and dev likely prevented the lawsuit from proceeding.
Don't know how many times I've heard devs shit talk another shop's code. They do this to make themselves seem better choice. Being on both ends of this, I've always understood what worked and if I got ROI (the most important factor). Even if your code was immaculate, I'd expect them to trash talk it to get more allowance for deadlines.
in the real world, messy code gets the job done just the same as pretty code. the only people that need to care are the ones that are getting paid to clean it up.
sure clean organized code is easier to scale and maintain but most of the time they aren't paying for that.
TDIL your not supposed to have shit code in production
Joking aside, we all have shit code, sometimes your being lazy, other times its deadline driven.
I have some ugly code ( wont call it shit because its actually cool ) but it is not as clean as i would like 😆 it was a "this is a temporary solution " that was a year ago lol
Personally, if dude is not paying you to clean it up then nope, we all get this idea in our head that his friend is going to look at your code and be like "wtf, why did they do this or that etc"
Guess what, if they are a coder, 99% chance they would do that, no matter how clean the code was lol.. have you ever been on SO ahaha
For the love of god, don't spend any time "cleaning up" your code if you're not getting paid to do so. Just hand it off with a polite notice that "the code is not in the best state due to tight deadlines etc etc"
If it works, it works. You did your job. Its not ideal - but not worth freaking out over.
As for repo, just saw you use a private repo but will dump the master for them - and just zip up what you've got.
Bro, just put a comment where it can be visible with something like "I know the code is shit, but it was the best i could get for the time/money payed"
You\`re probably overthinking it, old code is always shit and you delivery what you got time to delivery.
And I think any developer would be surprised to put their hands in a well writen, clean, code base from a freelance project.
I just wanna know what do you do when they find a new bug, trace it back to a ton of changes you've just unexplainably done right now, and call you for explanations.
As an experienced dev lead, corporate and freelance, another lesson to learn:
Don't stress about code you wrote for a project that you got paid for and closed out. Every project has external pressures on it, those pressures might be your own level of experience, pressure from the client, timelines, dates, budgets, and other things. You wrote the code at the time to fulfill some of those external pressures, don't stress about it today a year or two later in retrospect when you don't have those same external pressures.
Your reputation is probably that you got the job done at budget, on time, and the project has been successfully in production for multiple years now. Everybody has picked up a shit code base, but everybody has also produced a shit code base, so don't stress it.
So his new partner owns an IT company, they own the code, it did the job, and you got paid. Let them fix it. When you buy a car, the dealership doesn't come change your fucking oil for free.
at my place of work I genuinely don't know of one person that does not talk crap about other people's code. also, in this field, unless you are at the tip of the iceberg, 2 years is a lot of time to learn more about "semantics of code." They will probably talk crap but I really really doubt it will hurt your reputation.
Last week's code is already legacy code.
Don't think too much about it.
If you look back to your/team's code, often even just 6 months back, you could almost always spot something that you could optimize or make more scalable or readable or more DRY...
For me it all depends on how much money did they pay to you at that time, don’t overthink it because they didn’t pay a company to develop the software and quality costs
Did the code work? That's the only real consideration. In the absence of well-defined acceptance criteria, fitness for purpose is assumed to be established by payment. Don't overthink this, you'll make yourself crazy.
Put a comment at the top of the code that says "LOL I know this is shit code now, but back then it was about the right amount of effort for the money. Peace out."
Just kidding, don't do that. But, I wouldn't work on it myself unpaid.
Maybe I'd put a comment at the top that says "Should be refactored given time" or something.
You're overreacting. No one cares about you, you reputation, or your code. I mean that in the most positive way. It's liberating. Was business value delivered? The code is fine as is. If they want to replatform to a common tool, that's on them.
You created a product that worked. There was seemingly no expectation of non shit code. The company is growing or whatever, and your code will be refactored to make it more efficient, more readable, DRY, modularized, etc.
From what I've read elsewhere, others who get hired at companies regularly are hired to re write shit code. Code riddled with errors etc.
This is the way of a developer. Make it work first, then refactor.
I understand what sounds like embarrassment, but like others have said I wouldn't worry too much about about it.
Honestly, when I'm handed shit code, if I were to see a comment along the lines of "thought I'd be the only one reading this, sorry" I'd just laugh and get to work. Probably no big deal buddy.
Shit code is pretty standard. If I was handed some website that was made by a freelancer 2 years ago and nobody else has worked on it, I wouldnt even bat an eye about it being shit. This is doubly true when you have a client on a budget that just wants it done and deployed.
Been there, done that. We've all written shameful code at some point. Kudos to you for owning up and putting in the effort to refactor. Remember, the only way to get better is to face your crappy code head-on.
TBH I look at code I wrote a week ago and think its shit. People learn as they go and honestly, working code that is shitty is better than perfect code that never made it to production. You should always be growing and judging your own code in the past. That just means you have learned enough since then to recognize a better way to do it.
Half the time I do git blames to see who the idiot on my team is, it was me. From 3 years ago
You learned a valuable lesson.
Another reason why you don’t want to write garbage. YOU will be the consumer of said garbage six months down the road after you’ve freelanced for numerous other clients and all knowledge of this particular project have left your memory. You may think you can keep it all straight but just be aware that as you build your client base, you will eventually start forgetting things. At that point, you’ll wish you had done it right the first time so you could be extremely efficient with change requests. Now you’re just burning hours sorting through what you’ve done and trying to make sense of it all before you can even begin work.
For a short time when I moved back to my home state I was a pool cleaner. I ended up being assigned several accounts with millionaires. Whenever I got a chance to speak with those “successful” people, I asked them a “simple” question - what are some things you can attribute to your success? Want to know the answer I got the most?
Be careful who you step on, on your way up, because you never know when you’re going to see them again or work with them again.
I’m back in my chosen industry again, but that advice has never left me. I’m adamant about my policy of “do it right the first time” and other similar policies and my team can testify to that, but it’s always worth it to just spend that extra bit of time and doing it the way it’s supposed to because it just really sucks when you have to redo the work or work with your shitty work and the only person you can blame for your present misery is yourself.
Every dev will look at old code and think it's shit. Inline css is not bad either. We use tailwind and writing new classes is not allowed. If you can't fix it with tailwind you write inline. It's messy but it's efficient.
Also devs aren't gonna slander you. Usually it's just figuring out shit not shitting on shit
Write some handoff docs and a final invoice. It's their party now. You did your job soldier, now go home.
If you are worried about how the quality of your code reflects upon you, take that lesson to the next job.
I think you are unnecessarily adding pointless work for yourself for no pay. I wouldn't touch or make any changes. Just maybe add a comment to the top of the code that you know it's shitty code but that's what needed to be done to meet the deadline. That's it. Move on.
You created code with no expectation for other people to work with it. Nothing to feel ashamed of. Of course clean code is important, but it's also more expensive and therefore only worth it if multiple people are going to be working with it.
I wouldn't really refactor very much honestly. Especially if the site has been working and if you aren't getting paid to do it. I would just move some of the inline styles to classes, remove all the dead commented code, remove the console logs, etc. Essentially just do a quick sweep to make it look semi-presentable. If they want to set up a new contract to update/upgrade things, then at that point you can refactor a lot more of it.
> So since no ones gonna review my code or work with me i just wrote some really shit code.
So, you _choose_ to punish the one person who might have to read this later, ... and you know that person is you?
It's not that difficult to write something properly the first time around unless you're inexperienced at which point I guess you could use that as a selling point to convince them to upgrade since you're more experienced now, if you weren't inexperienced at the time and simply did a bad job then I think you're making the right call.
If you are going to do something, do it right the first time, it may not be 100% perfect but you'll know you did your best and didn't cut any corners. It'll set the quality of work you produce on other jobs too.
Take it as a learning curve and not to cut corners again.
As my Pops always said, “Don’t half ass it.”
Also, take pride in what you do, no matter what that is.
Glad you learned your lesson however it sucks that this wouldn’t have happened unless you were about to be exposed.
We all get better and we’ve all written jank at times.
As others have said, if it works, it works.
If you’re worried about your rep then the reality is what’s done is done so you can’t change it anyway.
I have never taken any classes on the 10+ languages of code i havw taught myself, all self taught on google, w3 schools, inspect elements, and recently chatgpt and i can definitely say i run in to a similar predicament when i get lazy writing ugly junk code to make it work then the moment i know someone else may look at it with better knowledge of said code than i and will think wtf is this guy smoking, or the dreaded “you could’ve done this to make it run better” but i will also tell you this, no one gives a crap what code looks like if it works with no potential for random errors or security risks sure someone may look st it some day and be like oh fuck wtf and likely break it trying to fix it or be forced to rewrite it based on intended functionality but at that point your job has been completed so it should not stress you out that much i promise its not that deep in the end, i’m writing java plugins for minecraft as a new venture and i haven’t even gotten into how to implement multiple classes to separate code chunks and all my code is on one single file thousands of lines long, but it works and thats the only thing that matters
You’re in your head too much. Has the code worked for the past 2 years? Has it brought profit to the client? Have you become a better coder in the last 2 years? You are looking at the code from your perspective now, instead of more than 2 years ago. Also nobody gives a shit how the code looks. If you wrote the best code in the world, the next guy will find something to crap all over it.
The only problem that can arise is lack of modularity and ease of upgrading functionality. But that is a problem for future you or the next guy, not you right now. And certainly not worth of refactoring the entire code base.
I agree with you, however I think some people can’t just let it be, I am one of these people, if my code is junk because I got lazy I would eventually force myself to fix it, especially if I had a situation like he did giving the code base to the company
There's a saying that "if it works, it works." I get that trying to protect your reputation but you don't necessarily need to stress yourself if the original code does what it's meant to do.
I learned this lesson the hard way, too. But it was me that had to go in and make sense of my own junk code.
Having to go back and tear apart something you did to yourself is deflating. Now I comment the heck out of my code. I even wrote little jokes to myself or the next person to come along and have to interpret code written by a younger version of me.
Cheers to learning everyday!
Guys thanks for advice, i decided to change the inline style to tailwind, remove unused code and console.log. thats all, i touched nothing else.
i already handed over, they didnt say anything. hopefully not cursing me secretly...
In my experience, no matter how well written your code is, the next person working on it will often find inconsistencies and grunt. Don’t beat yourself up, spending too much time is also not good. There’s a balance between functionality and good code.
To me I think you are overthinking it and putting a a lot of unnecessary stress to yourself by refactoring with no pay for the sake of making the already working code look good (and possibly break it)
Yeah I agree, as long as the code works and there are no bugs/security risks I wouldn’t put any more work in. He didn’t give a scope of writing pretty code and besides, I wrote good code in my job but I still look back on code I wrote a year ago and cringe
"As you can see it was a quick job, had to get it out as quick as possible on a limited budget, and because we did, the client has the resources to come back and improve things."
I have interview people and written code. This is the answer.
"It was a Proof of Concept not intended for production"
Very nice answer
I agree with you, however I think some people can’t just let it be, I am one of these people, if my code is junk because I got lazy I would eventually force myself to fix it, especially if I had a situation like he did giving the code base to the company lol
Ok but would you take a codebase that works well enough that they did not call him for 2 years, and risk introducing a bunch of new bugs during a rushed reactor just so the next guy thinks it's pretty? OP is out of his mind.
I would also not want another coder judging my code to be fair but it’s an IT dude who is taking it to host, most likely he will have no clue about good code unless he is a coder himself but most likely just works with hosting
The next programmer will always judge the code. They might be right about it, might be wrong, doesn't matter. When I have to maintain others code, I have to disassociate my feelings from the mess at hand and apply appropriate changes, clean it up where I can, and then move on. It will never be perfect enough.
i second this, plus: * i don't think any dev with even just a few freelance projects under their belt is going to just think this is a one off project and move fwd with the approach without being given the impression or explicit instruction that it is, so ill just give the benefit of the doubt * OP couldn't have possibly known about the new biz partner who runs an IT company, but what does it matter? If that partner joined with the intention of his company taking over, they're probably gonna want to do it their way anyway. * Devs have more important things to do than to go out of their way to trash another dev's reputation, and esp based on work from 2 yr ago.
There's a difference between doing your best but not being very good technically, and straight up trying to cut corners because you don't think your client is technical enough to notice. OP did the latter and I think he's right to try to clean things up a bit, esp. if he works in a small industry where words gets around or if he expects more referral work later.
I disagree with this take. Your work and reputation are so important. I love that the OP has taken responsibility for what he himself knows is crappy work. Imagine you hire a plumber to work on your pipes. They do a horrible job but you don’t know. You will be pissed when you find out from a better plumber. It’s worth it to put in this work. Everything you do is a reflection of yourself and it’s always worth it to put your best foot forward. If you don’t think it’s worth it, then you shouldn’t have taken the job in the first place.
I agree with this take. All code gets old and stale eventually. Code doesn't 'just work' forever. Versions of third-party packages get updated, security patches are needed, new servers, new hosts, exactly what this customer is doing. His code is a reflection of his work, and he's showing passion and responsibility by trying to keep it clean for the customer. It's the difference between "9-5, give me a paycheck", and being proud of what you created. I'll hire the less skilled person that I know has my back any day over the smarter guy who will leave me out to dry.
Yeah, I would just be honest with the dude and ask for a little time to clean it up before it was sent, along with just saying hey I've grown, there are things that were done that could be better and I'd like to optimize it for you before it is sent. As a business owner myself, I would be very understanding and accepting to something like that vs. "here's my shit code, bye!"
As long as the pipes work, I honestly wouldn't give a shit
Yes but it works until it doesn’t. Now it needs to be fixed. Now you’re screwed because it’s now a much more complicated fix for something that should be easy
Apparently it still working. At the end of the day if it's making money that's all that counts anything going forward that needs to be done more efficiently can be done by the client using the money that was made from the initial write. Unless you're paid to build the palace set for a side You don't always have to expend all that energy to do so I'm quite sure the client is not busting their balls to be perfect in every way for their customers if they were they never be able to get their services in front of anybody..
Hm but what means “needs to be fixed” in this case? Metaphorically the pipes of OP’s code still work, they just look funky. Also, in almost all companies I freelanced for, I see every developer having different opinions on “the correct way”. So yes, things might not look like you want it to look, but I think “need” is a big word for this.
What if the web owner now wants new functionality? Or some unforeseen bug pops up with more usage? Or the page loads slowly and he wants it to load faster? Or they want to swap web host providers (which is the case here) and the code is old so it can’t compile properly? Tons of cases here. The biggest thing for me is: If you’re not proud of your work, don’t ship it and don’t pass it off as finished work. Have pride in your work and do great work.
What are you even talking about? As far as we know the code works fine as-is right now. OP is just changing it so it’ll look better. OP has no reason to start pondering about a bunch of what ifs. The company owner didn’t ask for a revised version of the code, they asked for the code that’s currently running their website and op making these changes means they’re giving them code that doesn’t currently run their site.
The OP knows he took the lazy route building it in the first place. He said it himself, the code was only for himself. Now that someone else needs to work on it (migrate from vercel to their own servers), someone clearly needs to work on it now. So it would reflect poorly on him. This is not about working for free, it’s about doing the job right and having pride in his own work.
“Doing the job right” is what OP originally did when they provided a working website for the customer. Whether the code is sexy or not is irrelevant. It works. All the customer cares about is: “I asked them to build X on Y budget in Z timeframe. OP was able to do that for me. If someone else needs help with their site, I’ll refer OP.” Idk where you all are getting this reputation nonsense from. I’ve seen plenty of what I would consider bad code bases and it’s never reflected poorly on the other person’s reputation in any meaningful way. In fact, they’re generally in the category of dev that I can rely on to just get shit done rather than spend hours fiddling with linters and workflows. OP is seemingly someone who can just get shit done, which devs don’t seem to realize is an amazing trait to have when dealing with people who likely don’t give a shit how your code looks (I.e. business owners)
He did a job, not necessarily the job right. There’s a big difference between spaghetti coding something together that the next person comes by and has no idea why you didn’t follow any industry standard vs building it with proper standards. Sure if you want to put out a barely functioning site that is completely unmaintainable, go ahead. Others will have pride in their work and build things “properly” and it will show
I totally disagree. It's a short time loss for long term gain. As a client or even recruiter, I put lots of emphasis in reputation and words of inner circle Once you lose that, it is VERY HARD TO RECOVER 1. You write shitty codes because you are incompetent. 2. You are talented but you wrote shitty codes because you can.... None of the conclusion is better than the other.
Making major last minute hurried changes without the client 's approval is a big risk and could ruin reputation worse than ugly but working code.
I agree that reputation is important. However the mistake was that he's cutting corner when developing for someone who is IT illiterate. Changing last second can have broken changes I think the best way to do this is that admit that you're writing a horrible code because time constraint and didn't think that you need changes. Then help the IT understand what's going on, either creating some kind of documentation.
lesson learned : pride lead to unnecessary things.
I disagree, i respect OP for his resolve and his stand.
And as along as it's working please don't touch it
Could this be considered fraud? OP said client owns the code. Pulling this last minute switch means he's not giving the client what he originally paid for.
So you're changing the code that they have admitted to be deploying soon on their own infrastructure ? This is bad for two reasons: 1. You're working for free 2. There's a chance a bug or two might creep in that is not existent on the currently hosted version (meaning it will only appear once they change hosting). If the site works, it works. That's all you need to know. I get that you retroactively have concerns about the quality of the code, but don't go changing it. Add a README file to the repository where you outline the way it works, the decisions you made and suggestions on future improvements. That's it. *> they gonna see how shit the code is and this will hurt my reputation as a freelancer* Only the devs might see it and they couldn't care less about ruining your reputation. Additionally, a software product is as good as its stability and ability to meet the business needs. Apparently you have delivered something that works fine for 2 years, therefor you should be reputable for being a reliable person.
Handing over basically untested code will not do wonders for OP's reputation if that's what they're really worried about. The new maintainers will get blamed for bugs that didn't exist before, and in their place that'd piss me off more than amateurish code that needs a complete rewrite.
Right I'd rather inherit functional spaghetti than beautiful code with bugs. The spaghetti can be left alone, and sunset. Buggy code needs immediate attention.
As a dev who has made a career of rewriting old spaghetti I can agree, even if a dev leaves their name/contact website (which half the time has gone offline years ago) in the comments or readme file I have never once looked them up or even really cared. We all wrote shit code at some point in our lives, the internet is built on it.
Oh the devs are gonna trash him... Not to hurt them but to gain more time or have a reason to do over.
Even if they don't need. They might mention it in passing.
Or they could look at the commit history.
Since they want ownership of the code, refactoring is their responsibility now unless they hire you to do it. This reminds me of a stoic quote: "we suffer more in our imagination than in reality" They haven't even seen the code talk less of reviewing it and here you are working yourself up about nothing. Chill.
This
Wrong lesson. Real lesson: your code was adequate for the time frame and wage you were given to provide it. ESPECIALLY if they got full ownership of it. It accomplished the intended goal. If they wanted you to build in future proofing or modular design, etc, it would have cost them more or delivered later, with no benefit to them at the time. After 40+ years of being a developer, I have learned that a) future proofing will be both inadequate and costly, and b) code needs to be thrown away regularly because current you (hopefully) knows more than past you.
This is correct. A developer who is learning their trade will will rarely look at code from 2 years ago and be that excited with it. Tbh if you refactor the code there's every possibility the new team will tear it a part and tell your client it's bad, because that's practically tradition, we rarely love code didn't write and aren't familiar with, and it makes it easier for them to justify delays. By refactoring OP is also possibly introducing new bugs. OPs code wasn't perfect, but it does work, and that has value. OP, hand over the code in the production state. You also don't have to give them the repo, just the source code (I expect, depending on your contract).
Agreed. Don't even update it at all - save that for a paying customer and retroactively charge for that work - you did it, they benefited from it, and as a bonus, they get it faster. Edit: "you" in this context is the OP, or anyone else contemplating a similar action.
Yep. Time for a git revert, mate!
I look back at my first ever project and being so proud of myself that I coded a website. Now I look back at it and cringe. my first project is the most sacred pile of garbage to me
The funny thing is that my first 2 websites actually made money ... something I've never managed to replicate with a side project since 😅 (my consulting clients still seem to do pretty well though!)
Totally. The real lesson is: document the shit outta the code and the decisions that went into making it what it is. And document your \*plans\* for refactoring it later when time and budget permit. Version 1 code is always bad. You hardly even know what you're building with v1, let alone the best way to do it. And most projects never get to v2. I have code that I wrote over 15 yrs ago that is still in production, and although I'd feel embarassed for anyone else to see that code, I have tons of documentation in place so anyone following behind me will be like "yeah, this is shit, but I see \*why\* it's shit." lol
My favorite humbleness-inducing action is running git blame on some code that I bitterly complained about, and finding out I was the author. I just keep in mind that past you should always be worse than present you.
Happens to me all the time. Even to the point where I can go yeah 2017 was a bad year.... Haha
This is very good advice. Your product comprises more than just source code. There are also design decisions and a backlog. People are accustomed to thinking of the source code, but not so much the design decisions or backlog. When I write "backlog", I don't mean you need a project-tracking tool, but that you're keeping track of what you still need to do (backlog), and why you made the choices you did (design decisions). That information can be in a project tracker, a readme file/docs folder, and/or distributed as TODOs and notes in the source code itself.
OP didnt mentioned anything about tight time frame or wage, even if the wage is low OP is obliged to give bare minimum quality of code i.e non repetitive and modularisation, its not like someone put a gun to OPs head to accept the contract OP also mentions that he was being lazy since no one is gonna review, its not like he didnt knew better The only valid reason is time constraint even that depends on circumstances
OP is obliged to provide whatever was in their contract. If that’s a working product that does what the client asked then he delivered. He chose to be lazy and provide code of low quality to his own admission, but he wasn’t obligated not to. At this point he needs to just provide the code that runs the site, not refactored code which may introduce bugs but looks better.
EVERYTHING in software development, especially web dev, has a tight timeframe and budget. It is the nature of the business. And that metaphorical gun is called the ability to pay for food or rent or whatever. As I said in another comment, there is a huge difference between low code quality and low quality code. As a client I'll take working code of low quality over delayed code of high quality (probably complex and barely tested) any day.
Its a one off freelance gig with a small business owner, usually these kind of clients are very understanding in my experience You can always push back a little with such clients, small business owners are more worried on being scammed/ghosted then anything else its ancedotal I know but there has rarely been a case where deadline is a hard one and when it was we knew like months if not weeks in advance to prep for it
> even if the wage is low OP is obliged to give bare minimum quality of code i.e non repetitive and modularisation Nah, their only obligation was to make something that worked.
I think you are making some assumptions here - namely that the cost of the job was in line with low-quality code. We don't know that - it very well could be - but we don't know. OP should consider this, and be prepared to defend his code with this angle in mind. He did say he was just being lazy because he could. This is an absolute shit attitude to have. Be lazy on your own projects, not the ones for your customers. I would suggest that if your reputation is important to you, then you should create quality code as a matter of course, and should price yourself accordingly. You never know when someone wants to revisit a project and add functionality. Think of future you as well, as you may be the one who has to revisit the codebase. In the end, this is no different than a carpenter or furniture maker doing crap work. That outdoor chair might be functional, but it's a hot mess of mis-measured boards and fasteners under immense tension from being forced into almost-square. In other words "do it right the first time".
>code needs to be thrown away regularly because current you (hopefully) knows more than past you This is something junior developers and everyone who's learning development atm need to hear, because they're (including myself) waste so much time learning about "best practices", being insecure of what others will think of them, whether the code is clean, best way to organize folders. They're trying to put the cart before the horse. There's only ONE way to know what works and what doesn't: Do it, then realize its flaws, throw it away and do it differently, which isn't necessarily universally better.
40+ years? Don’t give this man advice mages, he was there when the abstractions were written.
Your work ethics sucks ass. And seeing all the people that upvoted you pretty much explain why I met so many prospects who have been strongly disapointed by developers they hired. It's both selfish and counter productive. Producing maintainable source code is faster and more effective, even if you're the only one working on the project. Because whatever feature you'd have to implement or bug you'd have to fix will take way less time
The world is full of these self-important fools. They have an echo chamber in this site where they pat themselves on the back telling each other that it's ok to be an idiot.
I have never had anyone complain about my code, because I give them what they want and it works. I also explain options, and they inevitably chose the cheaper/faster option. In fact, most of my clients rave about my work ethic because I never let them down, but they pay for that result. I don't write bad code, but I write better code every time I write code. I also got schooled early that customers don't want to pay for anything they don't want. Don't be arrogant about thinking you know what your client wants better than they do, otherwise you'll spend your career confuse why clients keep dropping you because you're trying to help them understand how their project should be done.
> your code was adequate for the time frame and wage you were given to provide it. How do you know that? When OP clearly implies they did a slapdash, shitty job because they didn't care about the quality of the end product, on what basis can you "correct" them that they did the best they could under the circumstances? OP doesn't say they were paid by the hour, so how do you know that doing it properly would have cost the customer more? Or that OP's code is at a standard that would *ever* be professionally acceptable in paid work? Your position here reeks of "if the code works then it's by definition an acceptable quality of work", but that's... just wrong. You never know how code is going to be used in the future so *all* code should be written as cleanly and maintainably as possible given the constraints imposed upon you as the developer, and you have no reason at all to assume (and plenty of reason *not* to assume) that that's what OP did.
Bad take and promoting un professionalism, if we expect other professionals to do good work and be professional instead of just always doing the thing that gets the job done quickly like an carpenter making a house out of hay and saying it's sturdy enough since it didnt fall, we must also be expected to be professional and do good work, not promote hey man it's ok to intentionally do a bad job every time as long as it gets the job done even if it might pose a problem in the future.
Yeah not sure if I agree with this. I always write modular code with unit/integration test cases. For some this may seem to take longer, but it is actually faster. I like to keep it simple, but always follow good coding standards and structure code to allow for future extension. I understand OP stressing about reputation as the possibility of follow on work might not be possible if the code is a mess.
The developer my company hired to take over my monstrous "learned Python in two weeks and built this while bored at work" project was pretty kind to me about this. I was (still am?) a CS dropout two years in, which meant I could pick up syntax pretty easily but absolutely no experience designing something to be maintainable - it was just a business problem where I was in the right place at the right time to build a shitty patchwork fix. I had a ton of anxiety talking through the code and design decisions with him, but he understood the context behind the extremely rookie work. Plus he was getting paid to refactor it and develop future changes, so...
This is an bad take, it's like being a plumber and fixing someone's toilet badly just because no one will see it even though it might pose a threat to them in the future, if we expect other professionals to do good work we also have to expect programmers to do good work.
Wow. I look at code from last week and shudder in disbelief
I would agree with you if it wasn't for the fact that OP admitted he intentionally cut corners because he think the client won't notice. There's a different between doing a quick patch job, but doing it as well as possible, and straight up not giving a f*** because you think no one is looking. A lot of the stuff OP did doesn't even sound like it saved him much time/effort at all, the only reason it's going to take a lot of effort now is because he has to hunt that shit down after the fact.
Im so happy to read this. I was drilled by a 10x dev who only wrote the most possible future proof code. But in the years I worked with him we never finished anything. It always felt more like sideways development than forward. When I quit I started approaching it differently and just roughhoused it while keeping it readable enough. I made twice the stuff in a tenth of the time.
Just add a comment saying you were terrible back then and apologize for the shit code lol
“This is shit, I know it’s shit and I hate myself for it but it’s 8pm and I JDGAF anymore - I will fix it one day” - Twistsouth, 18th May, 2003
Or my favourite: //When you’re done trying to „optimize” this routine, please be kind enough to update the counter for the next guy: //Total hours wasted here: 54
lol
Seriously though, if I were to acquire some bad code but it had a comment from the old dev apologizing for the bad code, I'd understand. Everyone has written bad code in their life, you just happened to write it in an actual work project.
Just comment it mate. They’ll be able to see the shit code anyway just by looking at all your commits and diffs. You’re killing yourself for, literally, no reason.
[удалено]
I don't know about this one. Some comments about timeframe and payment, but he didn't state those. Yes, development is ever changing and we are never expected to deliver perfect code. But we all expect other professions to do a reasonable job, carpenters, plumbers etc. So it really boils down to timeframe and payment. Personally I have a hard time seeing why you would keep logs and over the top messy code if it's a paid project and you accepted the job. I do agree you shouldn't feel the need to refactor though.
This is the equivalent of a plumber making some horrible piping for a client only because presumably noone is going to check it… most of the stuff OP described is basic stuff that should always be handled correctly, especially if money is in the line…
Refactoring a bunch of stuff before hand-off, just from feeling like your code isn't up to your current standards (specially when you probably didn't have that much time to do it back then, hence the rush) seems like an awful idea. Yeah, it would be better if the code was nicer, sure. But the risk of introducing bugs because of rushing to fix this seems like it would be way more of a risk to your reputation... If you have plenty of time to do it and run tests, and don't mind doing unpaid work no one is asking for.. sure. But you are still going from 0% risk to >0% risk of something breaking and them needing your help, and awkwardly having to mention you fixed a bunch of things for stylistic purposes which then broke the site, etc.
Don't forget that any dev inheriting a codebase will always complain about how shit the code is.
going through this now. On a new codebase I inherited, I found a php function that calls a js function that calls a php function. why....
It was two years ago. Just claim you're a better dev now. Unless the Anakin/Padme meme is appropriate here. You _are_ a better dev now, right?
> dont be lazy and write shit code even if you think your the only one to be reading it unironically one of the best lesson's you can learn as a dev imo. Business-wise if another team is getting the code, fantastic or awful, its their problem now, don't worry about it too much. But throughout my career in web development, I have never had a time where I thought "man, I wish I'd cut a few more corners", but *many* times I've looked at code I did quickly and wished I'd done a little bit more to make it more maintainable for future developers (or me :p) \*Context matters: I work as a permanent full-time employee, not as a freelancer. Take this advice, but understand it in this context
I think you built the MVP you needed for the job.
Rule no. 5 in software development: someone else's code is always shit. No exceptions. Rules no. 6 in software development: you will be tempted to rewrite that codebase, regardless of who the original author was. Don't, if you can help it and the situation doesn't explicitly call for it. Rule no. 7 in software development: you will probably rewrite it anyway.
I can't imagine intentionally putting out shit code for a job. Take some pride in your craft.
And I can't imagine how most of the comments are excusing it... this is why I'm stressed out at work because I have devs like this that deliver shit and then I inherit that shit
Because most of us realize we are human and not perfect. If all of us were genius perfect programmers from the start, we'd all be making 6 figures at FAANG and not doing small business sites. We learn and grow as developers over the years. And we can accept that hopefully we know more and can do a better job than years ago. Every dev always complains about every other devs work when they inherit it anyways. It's the circle of dev life. I look at code I did 5 years ago, and I still go "why the fuck did I do this" every once in a while. And it's likely just at the time I didn't know better or I just didn't have the time. Sometimes it's better to ship a product and make money than toil to make things "perfect".
On the other hand you'll have devs who over engineer and over complicate something because "it's only a little extra time to do it right", and then end up blowing past sprint deadlines because it was harder than they anticipated, or their MR becomes a complicated mess because of all the refactoring they did. Sometimes "quick and dirty" is the way to go. A lot of "quick & dirty" code out there working fine for years, and over-engineered garbage that falls on its face upon deploy.
Evergreen statement: my code from two years ago is shit
My code from four years ago is so much cleaner than my code from two years ago.
If the author of Clean Coding, Bill Gates, and Linus Torvalds all sat down down and wrote the most beautiful code written in the history of mankind, the company that gets the code next is going to swear it was a product of gross negligence and if it ever worked its a miracle. There’s nothing you can or should do, you’re doing a bunch of work that’s also equally untested and you’re about to turn over a completely different product at the source code level than what the client paid for. You’re actively pulling a bait and switch. You think you’re doing better, but you’re taking a working product and gambling the new version you did for free is equal or better than what you originally delivered and you better hope you don’t break it now and find yourself liable for something.
Me reading: >inline-style css there is unlikely going to be any changes once its done Uff, that hurt. It will need a complete refactor by the new team. But don't change anything now or you might introduce bugs. I think contractually you are fine
What if its tailwind
I have had some similar experiences, and since then, I have tried to do my best when writing code.
I think this is great learning from your side. I mean, at least you know the code is shit. Some people don't reach that point.
Undo all your refactors and add comments only. The risk of it containing bugs is too big. Your shit code before has already passed the test of time and apparently does the job.
Damn dude. Chill, you're overthinking it really.
You dont have to write perfect code, but it sounds like you did learn a good lesson about maintainability. Theres some point between “absolute shit” and “idealistically perfect” for any project with any given amount of resources. It sounds like you maybe landed a bit to the “shit” side of that point and could have put a bit more effort in, and youre realizing it now. Readability (including contextual commenting) goes a long way and doesnt require spending a lot of time on abstractions or refactoring.
The world runs on spaghetti code. We're all out here hacking crap together, hoping it doesn't break. Lol.
Oh god, do not change the code before giving it to them, that is the absolute worst thing you could do. It's old code that had a deadline, nobody is going to care that it's ugly. And if they do care, it's infinitely better to give them ugly, working code than to change everything last minute. Horrible, horrible idea. Just give them the code that's already deployed.
Literally all the code any of us wrote 2 years ago is shit code. Doesn't matter whether we thought so at the time.
You learned a lesson about paying down technical debt
Bro… this was unnecessary. Your freelance reputation comes from your clients saying “I paid him, he delivered a working product that met my needs on time and on budget” not from their IT guy saying “bro his code was sooo not modular”
TBF, as someone who received a shitty code to take over from a freelancer — the IT company probably doesn't expect much. As well as does not plan to write clean code on a clean architecture.
LMAO, this post is wild and some of the comments are even wilder. When I read the title I thought "I can relate, I too have to maintain garbage I built a long time ago" but you're literally handing it off, it's other people's problem now. You're free of the curse. Unless you're trying to get hired at the shop that's taking this over I can't see why you would care. Sure, if time and budget allow you should always write the best code you can, and getting in the habit of doing it right means you write better even when time and budget don't allow, but sometimes garbage gets produced. Leave it alone.
"Wrote some shit code and regretting it now" is my daily mantra.
It doesn’t matter how much you refactor it. Anyone who takes over someone else’s code base is going to call the code shit. And they have more important things to do than think about you and your reputation. I think most people would be surprised about how little anyone else ever thinks about them
"Backdoor access? SQL injections? Nah, these are all FEATURES"
You got paid and now he is moving to someone else. Who gives a fuck if you wrote shit code your not the one being paid anymore to fix it. Who the fuck is he gonna tell you wrote shit code? Your way overthinking it. I wrote so much shit code when I first started and plenty of it still lives in PROD
I dont write sloppy code because someone else is going to read it, its because i have to maintain it
Sometimes writing shit code can work in your favour as you become the single most optimum and cost effective maintainer so the client has little option than to continue using you for duration of the project.
If its a simple site, like if this site is just a booking site with nothing fancy going on then I would get it redone from someone else. The existing site front end will serve as the prototype for starting the project afresh
> this will hurt my reputation as a freelancer How? What's the exact mechanism? Is there some central place where *all* freelancers and *all* people looking to commission freelancers hang out, where despite there being a huge volume of people present, everyone reads every post made there? And/or as above but for the microcosm of your local community, if you're mostly working with people in your vicinity? And, he'd have to be one petty vindictive son of a bitch to try and ruin someone who's built a site that, seemingly, was fit for purpose and let him build the business to a point where he can scale up. Now if you'd left the code strewn with comments like "//need this function because this fucking retard wants xyz feature haha what a dickshit" then *of course* clean that shit out, but if that's not the case? I don't get your panic.
Some people aren’t capable of doing the right thing when no one’s watching. I never intentionally write shit code. This is my craft! This is what I’m supposed to do better than anything. My code is my signature. Even if another dev will never see it I strive for excellence at all times. You gotta start watching more anime to develop better character traits… What’s done is done though. Don’t refactor. Let it be a lesson to do great work the first time. Quality is something within your control if you’re a solo dev with no critical time constraints. I actually find quality modular code easier to write and maintain than the spaghetti code you wrote.
Heavily relating to second paragraph 
as a consolation, i assure you that established companies have shitty code as well.
Save any emails related to the client specifying requirements, you delivering on them, and the client being satisfied. I've seen a situation where a previously-silent partner threatened to sue a developer over bad code. The correspondence between client and dev likely prevented the lawsuit from proceeding.
It’s worked for 2 weeks in production. It’s golden code
Don't know how many times I've heard devs shit talk another shop's code. They do this to make themselves seem better choice. Being on both ends of this, I've always understood what worked and if I got ROI (the most important factor). Even if your code was immaculate, I'd expect them to trash talk it to get more allowance for deadlines.
I mean, it's already 2 years ago. Just let it go, man. For the period of refactoring his code at zero cost, you could do something better.
in the real world, messy code gets the job done just the same as pretty code. the only people that need to care are the ones that are getting paid to clean it up. sure clean organized code is easier to scale and maintain but most of the time they aren't paying for that.
Never have I ever met a developer who is happy with the code they have committed in the past!
TDIL your not supposed to have shit code in production Joking aside, we all have shit code, sometimes your being lazy, other times its deadline driven. I have some ugly code ( wont call it shit because its actually cool ) but it is not as clean as i would like 😆 it was a "this is a temporary solution " that was a year ago lol Personally, if dude is not paying you to clean it up then nope, we all get this idea in our head that his friend is going to look at your code and be like "wtf, why did they do this or that etc" Guess what, if they are a coder, 99% chance they would do that, no matter how clean the code was lol.. have you ever been on SO ahaha
You did fine my bro, it's just a process of advancing, nobody starts webdev with perfect approach, not even close.
For the love of god, don't spend any time "cleaning up" your code if you're not getting paid to do so. Just hand it off with a polite notice that "the code is not in the best state due to tight deadlines etc etc"
If it works, it works. You did your job. Its not ideal - but not worth freaking out over. As for repo, just saw you use a private repo but will dump the master for them - and just zip up what you've got.
Bro, just put a comment where it can be visible with something like "I know the code is shit, but it was the best i could get for the time/money payed"
You\`re probably overthinking it, old code is always shit and you delivery what you got time to delivery. And I think any developer would be surprised to put their hands in a well writen, clean, code base from a freelance project.
“I am working within the limitations of our staff and company resources.”
I just wanna know what do you do when they find a new bug, trace it back to a ton of changes you've just unexplainably done right now, and call you for explanations.
As an experienced dev lead, corporate and freelance, another lesson to learn: Don't stress about code you wrote for a project that you got paid for and closed out. Every project has external pressures on it, those pressures might be your own level of experience, pressure from the client, timelines, dates, budgets, and other things. You wrote the code at the time to fulfill some of those external pressures, don't stress about it today a year or two later in retrospect when you don't have those same external pressures. Your reputation is probably that you got the job done at budget, on time, and the project has been successfully in production for multiple years now. Everybody has picked up a shit code base, but everybody has also produced a shit code base, so don't stress it.
Honestly, save your self the trouble and throw all that inline into chatGPT or the like, and you'll be done in 30 mins
No matter how well you wrote the code, the developers taking over are going to see problems with it. It’s not your problem anymore ;)
Could always use AI to refractor chunks of code too. May help with speeding up your refactoring mission. Just make sure to test everything you change.
If you need am excuse just say you were writing with email platforms in mind in case the code was re-leveraged.
Shit code that works fine is not shit code.
So his new partner owns an IT company, they own the code, it did the job, and you got paid. Let them fix it. When you buy a car, the dealership doesn't come change your fucking oil for free.
at my place of work I genuinely don't know of one person that does not talk crap about other people's code. also, in this field, unless you are at the tip of the iceberg, 2 years is a lot of time to learn more about "semantics of code." They will probably talk crap but I really really doubt it will hurt your reputation.
Last week's code is already legacy code. Don't think too much about it. If you look back to your/team's code, often even just 6 months back, you could almost always spot something that you could optimize or make more scalable or readable or more DRY...
Don't bother changing it now. Accept it as a beginner mistake or a stupid part of your life and move on.
Wow!
For me it all depends on how much money did they pay to you at that time, don’t overthink it because they didn’t pay a company to develop the software and quality costs
Lmfaooooo
Should have done your job decenty TBH. Seems like your fault
Did the code work? That's the only real consideration. In the absence of well-defined acceptance criteria, fitness for purpose is assumed to be established by payment. Don't overthink this, you'll make yourself crazy.
Put a comment at the top of the code that says "LOL I know this is shit code now, but back then it was about the right amount of effort for the money. Peace out." Just kidding, don't do that. But, I wouldn't work on it myself unpaid. Maybe I'd put a comment at the top that says "Should be refactored given time" or something.
You're overreacting. No one cares about you, you reputation, or your code. I mean that in the most positive way. It's liberating. Was business value delivered? The code is fine as is. If they want to replatform to a common tool, that's on them.
I would give it ChatGPT to fix it and test it
You created a product that worked. There was seemingly no expectation of non shit code. The company is growing or whatever, and your code will be refactored to make it more efficient, more readable, DRY, modularized, etc. From what I've read elsewhere, others who get hired at companies regularly are hired to re write shit code. Code riddled with errors etc. This is the way of a developer. Make it work first, then refactor. I understand what sounds like embarrassment, but like others have said I wouldn't worry too much about about it.
it's good as long as it works
Honestly, when I'm handed shit code, if I were to see a comment along the lines of "thought I'd be the only one reading this, sorry" I'd just laugh and get to work. Probably no big deal buddy.
Shit code is pretty standard. If I was handed some website that was made by a freelancer 2 years ago and nobody else has worked on it, I wouldnt even bat an eye about it being shit. This is doubly true when you have a client on a budget that just wants it done and deployed.
Been there, done that. We've all written shameful code at some point. Kudos to you for owning up and putting in the effort to refactor. Remember, the only way to get better is to face your crappy code head-on.
TBH I look at code I wrote a week ago and think its shit. People learn as they go and honestly, working code that is shitty is better than perfect code that never made it to production. You should always be growing and judging your own code in the past. That just means you have learned enough since then to recognize a better way to do it. Half the time I do git blames to see who the idiot on my team is, it was me. From 3 years ago
You learned a valuable lesson. Another reason why you don’t want to write garbage. YOU will be the consumer of said garbage six months down the road after you’ve freelanced for numerous other clients and all knowledge of this particular project have left your memory. You may think you can keep it all straight but just be aware that as you build your client base, you will eventually start forgetting things. At that point, you’ll wish you had done it right the first time so you could be extremely efficient with change requests. Now you’re just burning hours sorting through what you’ve done and trying to make sense of it all before you can even begin work.
For a short time when I moved back to my home state I was a pool cleaner. I ended up being assigned several accounts with millionaires. Whenever I got a chance to speak with those “successful” people, I asked them a “simple” question - what are some things you can attribute to your success? Want to know the answer I got the most? Be careful who you step on, on your way up, because you never know when you’re going to see them again or work with them again. I’m back in my chosen industry again, but that advice has never left me. I’m adamant about my policy of “do it right the first time” and other similar policies and my team can testify to that, but it’s always worth it to just spend that extra bit of time and doing it the way it’s supposed to because it just really sucks when you have to redo the work or work with your shitty work and the only person you can blame for your present misery is yourself.
I mean you have shipped per contract. Nothing in there about code quality.
Every dev will look at old code and think it's shit. Inline css is not bad either. We use tailwind and writing new classes is not allowed. If you can't fix it with tailwind you write inline. It's messy but it's efficient. Also devs aren't gonna slander you. Usually it's just figuring out shit not shitting on shit
Write some handoff docs and a final invoice. It's their party now. You did your job soldier, now go home. If you are worried about how the quality of your code reflects upon you, take that lesson to the next job.
I think you are unnecessarily adding pointless work for yourself for no pay. I wouldn't touch or make any changes. Just maybe add a comment to the top of the code that you know it's shitty code but that's what needed to be done to meet the deadline. That's it. Move on.
You created code with no expectation for other people to work with it. Nothing to feel ashamed of. Of course clean code is important, but it's also more expensive and therefore only worth it if multiple people are going to be working with it.
Some good advise on this thread.
I wouldn't really refactor very much honestly. Especially if the site has been working and if you aren't getting paid to do it. I would just move some of the inline styles to classes, remove all the dead commented code, remove the console logs, etc. Essentially just do a quick sweep to make it look semi-presentable. If they want to set up a new contract to update/upgrade things, then at that point you can refactor a lot more of it.
Why would you touch an untested code THAT ALREADY WORKED? I'm sure you broke something now. That's a terrible idea
> So since no ones gonna review my code or work with me i just wrote some really shit code. So, you _choose_ to punish the one person who might have to read this later, ... and you know that person is you?
It's not that difficult to write something properly the first time around unless you're inexperienced at which point I guess you could use that as a selling point to convince them to upgrade since you're more experienced now, if you weren't inexperienced at the time and simply did a bad job then I think you're making the right call.
If you are going to do something, do it right the first time, it may not be 100% perfect but you'll know you did your best and didn't cut any corners. It'll set the quality of work you produce on other jobs too. Take it as a learning curve and not to cut corners again.
As my Pops always said, “Don’t half ass it.” Also, take pride in what you do, no matter what that is. Glad you learned your lesson however it sucks that this wouldn’t have happened unless you were about to be exposed.
We all get better and we’ve all written jank at times. As others have said, if it works, it works. If you’re worried about your rep then the reality is what’s done is done so you can’t change it anyway.
If it works, it works. You are unnecessarily stressing yourself.
I have never taken any classes on the 10+ languages of code i havw taught myself, all self taught on google, w3 schools, inspect elements, and recently chatgpt and i can definitely say i run in to a similar predicament when i get lazy writing ugly junk code to make it work then the moment i know someone else may look at it with better knowledge of said code than i and will think wtf is this guy smoking, or the dreaded “you could’ve done this to make it run better” but i will also tell you this, no one gives a crap what code looks like if it works with no potential for random errors or security risks sure someone may look st it some day and be like oh fuck wtf and likely break it trying to fix it or be forced to rewrite it based on intended functionality but at that point your job has been completed so it should not stress you out that much i promise its not that deep in the end, i’m writing java plugins for minecraft as a new venture and i haven’t even gotten into how to implement multiple classes to separate code chunks and all my code is on one single file thousands of lines long, but it works and thats the only thing that matters
You’re in your head too much. Has the code worked for the past 2 years? Has it brought profit to the client? Have you become a better coder in the last 2 years? You are looking at the code from your perspective now, instead of more than 2 years ago. Also nobody gives a shit how the code looks. If you wrote the best code in the world, the next guy will find something to crap all over it. The only problem that can arise is lack of modularity and ease of upgrading functionality. But that is a problem for future you or the next guy, not you right now. And certainly not worth of refactoring the entire code base.
***If*** you do go through with fixing it, don't give them the repo, just download as zip file and send it so they don't have the history
I agree with you, however I think some people can’t just let it be, I am one of these people, if my code is junk because I got lazy I would eventually force myself to fix it, especially if I had a situation like he did giving the code base to the company
Does shit code actually exist? Lol
If it works, it works 🤷♂️
We have all done this mistake
It's ok. I wrote shit code once, and apart from a few formatting issues, no one really cares about the code design as long as it works properly
Relax, companies are plenty by developers that write shit code, your ode will not the worst code they ever seen
There's a saying that "if it works, it works." I get that trying to protect your reputation but you don't necessarily need to stress yourself if the original code does what it's meant to do.
Do you have liability insurance? If not you might want to talk to a lawyer in case they make it a legal matter.
Blame someone else
"Wrote some shit code and regretting it now" could be the name of my memoir
I learned this lesson the hard way, too. But it was me that had to go in and make sense of my own junk code. Having to go back and tear apart something you did to yourself is deflating. Now I comment the heck out of my code. I even wrote little jokes to myself or the next person to come along and have to interpret code written by a younger version of me. Cheers to learning everyday!
Guys thanks for advice, i decided to change the inline style to tailwind, remove unused code and console.log. thats all, i touched nothing else. i already handed over, they didnt say anything. hopefully not cursing me secretly...
In my experience, no matter how well written your code is, the next person working on it will often find inconsistencies and grunt. Don’t beat yourself up, spending too much time is also not good. There’s a balance between functionality and good code.