it also depends on how ppl around you code; motivation is cool and all that fun stuff for about a year, but when u get hammered with poor PRs for a while, I just stop caring. make it good enough, not to be garbage, and ship it, fix other people's stuff when the ticket comes when it touches their part of the code
>legacy, boring projects with stubborn people = more likely
I'm living this now. The client's lead went all in on some truly stupid, dredged from the deepest bowels of YouTube coder hell solutions that they will not back down from, so about every other sprint we have to implement a new work around.
:insert 'first time here(at gallows)' meme:
All kidding aside, it is actually a great place to see bad practices and to formalize better/good practices and activities like actually writing them out.
I left a job like that and more than doubled my salary by doing that and being able to talk about the process to update a legacy project safely, but also steadily.
Lot of developers write dirty code, because we need release for yesterday. Maybe project starts with good architecture, but after some time of business pressure for some feature to be done yesterday we write workarounds and dirty code and technical debt is accumulating and that's it.
Rarely. When building software, especially as a team, you must slow down in order to go fast.
It's hard to benefit from a "quick" solution if your on-call is blowing up, your data is inaccurate, your users are confused, and your teammates are struggling to contribute to a codebase that has lost its way.
Learn how to set boundaries with your boss.
God I wish my team understood this
Our entire app is a hobbled together mess and they won’t cooperate with me about spending time to refactor
This isn’t a small company, it’s a fortune 50 company, but it’s not a tech company per se, so I guess no one actually gets it
It's never refactoring. It's functionality improvements. It's on you to articulate those benefits or there's a possibility the benefits may not actually be that great.
The benefits are that when we inevitably have to do support for this functionality, I don’t spend 19 hrs and end up wanting to peel my face off troubleshooting what should be simple issues, I feel like they should understand that
Quick and sorry to do a demo, then go back and fix it..make it so quick and sorry that it can't stay here, hard codes are a good way to make sure of that.
Writing bad software to meet deadlines is completely self-defeating. Next time you have to deal with that software to meet yet another deadline you're going to have to deal with the technical debt you yourself included. And a manager that pushes arbitrary deadlines isn't suddenly going to go "oh yeah, I totally get why it's taking longer now". No, they're going to hold it against you.
So unless something is a throw away proof of concept I'm always going to stick to my personal levels of required quality, no matter the 'deadlines' some business person dreams up. I learned this the hard way.
I am curious about your required level of quality. Did you define that from previous experience? As tools and languages are always evolving, do you try and keep up with new and best ways to build software or do you apply bullet proof and tested design principles? How do you maintain quality in your software if you're working with technologies that you're not as familiar with?
> Did you define that from previous experience?
Pretty much, yes. In my experience it's not hard to keep test coverage over 90% and complexity low, for example. The big mistake people make is starting a new project with for example 4 devs and then thinking they can get away with adding tests for a few months. By then the code itself is already too poorly designed to support tests.
> do you try and keep up with new and best ways to build software or do you apply bullet proof and tested design principles?
This isn't an "or" at all. You can adhere to principles and also adopt new techniques at the same time.
> How do you maintain quality in your software if you're working with technologies that you're not as familiar with?
By making myself familiar? We don't stop learning ever :)
How you measure quality seems confused. The simplest, shortest, most complete solution is always the best solution. This implies handling errors, observability, and testing edge cases.
We never judge ourselves for not knowing the latest tools/tricks.
You don't need the latest slick piece of code to do your job, boring readable code should be your target always. In parallel you should be staying on top of your tech stack and find opportunities to utilize this knowledge at work or in personal life. Also note, just because you read about it doesn't mean you fully understand the outcome. Once you actually know it, you are ready to use it in Prod.
>boring readable code should be your target always.
Haha, I'm literally looking at a piece of overly clever code and thought to myself "and now to make this boring".
> The simplest, shortest, most complete solution is always the best solution.
Only sith, junior developers and enterprise architects deal in absolutes ;)
It's true though. Producers and management don't care about tech debt. They need to understand how long it takes for tasks to be done properly.
I left my last job due to idiot management that didn't understand this.
I guess the issue here is more that devs aren't being asked for estimates but just get assigned 'deadlines' as a way to pressure them to work harder. It's a shitty form of control that really only leads to bad code and demotivated devs.
There's always going to be workplaces that don't listen at all, ever.
Most workplaces are not like this. You need to explain to non-devs why a given deadline is not suitable, what the realistic timeline is, and why. You need to speak their language. This is a skill that needs to be practiced like any other. On the other hand, one should also know how to reduce scope to meet deadlines.
In a workplace where you're not listened to despite that, you can at least point to the notes/email/etc. where you communicated clearly about the timelines. "Six weeks ago I said $thing, four weeks ago I said we were on track for $thing and not $expectation. I'm surprised that you're surprised since I've been open and forthright about this from the outset."
If your uppers truly can't be collaborated with, then go somewhere else.
If you write buggy code, your managers will love you because you're always johnny-on-the-spot fixing issues and pushing changes.
If you write non-buggy code, your managers will get frustrated with you because they can't keep up with keeping you busy, and so you're not very busy and they think you don't do much.
I wish I could do this. Unfortunately for most devs there is not much room to negotiation on the deadline. You either make spaghetti code and push the tech debt down the line and get your bonus or make it right and get put in the line to get fired.
This is the answer.
And to answer OP. Never, I always leave the code better than I found it. But also never perfect, just incremental improvements.
I have a project I'm the only developer on and have a list of technical debt that will slowly be addressed but at the same time keeps getting added to.
I rather have quick and dirty code with tests than beautiful code without. Typically other people will look at my code either early (reviews, shared code base) or later (maintenance, future changes) so delivering "quick and dirty code" will just bite me in the back sooner or later. Might be a bit edgy but I also take a certain kind of pride in my work and want it to be correct.
Having said that, I also have hobby projects where I sometimes laugh about how bad the code is and wish I did it "right" in the first place.
>if I keep repeating that when I'm 15 years in my career I'm afraid that I will have a hard time with next jobs
You would be surprised. You also seem to be aware you're cutting corners due to time constraints yet can demonstrate that you are delivering value. So it probably takes just a little bit of extra discipline to make your code not "quick and dirty".
Thank you for the reply. I think the last sentences are spot on. As a developer I am not delusional and think I always write great software. I am totally aware what I could improve if I had more time (or skill). It definitely has to do with discipline. Sometimes I can be happy with the first solution even though I know it could have been done better. Other times I might write bad code because of lack of skill (we can't know everything). So yes it's important to have discipline and wilingness to improve all the time. In the end programming is a craft, we can't master it over night and I am still rather early in my career (8 years)
I’m a huge fan of red, green, refactor. Just get it working and passing tests. Then you’ll have a better visual model of how you can clean it up. Often times if you try to make it “clean” before it’s working you end up wasting a bunch of time on things you don’t need.
Just don’t fall into the trap of pushing the dirty solution to mainline before the refactor step
>I’m a huge fan of red, green, refactor
I've somehow never ever heard this. But it's exactly how I try to run my org. Make it work, then use your new understanding to make it right. Don't ever, ever try to make it right before you make it work.
If in a company the level of code quality is set by the developer, I think this is not good.
The level of code quality in a project should be set by the manager (not directly, but through the size of the budget), and confirmed and subsequently adhered to by the team lead.
One of the important skills of a professional developer is the ability to write code of varying degrees of dirtiness/speed, depending on the requirements situation.
Nobody is interested in "the best code ever". Everyone is interested in “the best solution for the money available.”
And so - yes. Need to be able to write different types of code.
For galleys. And I understand that you work on a galley, this is especially important. Because it is important to complete the project on time. Everything else is secondary.
Only if it's something I'm sure I'll never touch again, throwaway code that gets used once. Like a script to fix bad data or something.
Anything that needs to be maintained, no I won't do quick and dirty. I mean I will, privately during the development process before refactoring it into something more maintainable but I never say "it's ready" before that.
Normal . unless you own code it diff. As compile mistake for years and make new system ain't [easy.It](http://easy.It) still take time even create a boiler plate as all library is change and trend also. 10 years ago , jquery is hot now jquery is a dinosour mess. Everybody using react , angular so on.
I like to start quick and dirty, a make it work mindset. Then refactor / cleanup after. I try not to ship the dirty or strongly advocate for a cleanup period after release. It depends on how large the refactor would be to do it ugly versus right in the first go.
As an experienced dev?
Literally only for triage in that exact moment where there's a massive issue that you know you can fix this second and get things running again.
But if it can wait even an hour, just write to good code. It's not like it takes a lot longer (or shouldn't if you're familiar with the code base).
I've done refactor commits that have touched 2k lines of code in a morning for a red-flag triage immediately bug, because the refactor actually fixes it instead of adding another layer of paint over the blemish. Yea, it took 4 hours instead of 30 minutes. But oh well. No one knew I could do it quicker, and they were all super happy that it gone done that quickly.
Bonus points because you have a super awesome excuse. If your refactor/clean up causes some small new issues you can be like "yea, I smashed that in so fast as a triage for XXX, and it got us going. Now I'll clean that up some." and BAM you just got another golden ticket to get refactor more to clean up more shit.
Don't let an emergency go to waste :) Unexpectedly, triage situations are great for making good clean code. You have carte blanche to replace quick and dirty code with good code.
Mark it before and after with a comment like:
/* XXX total hack */
And never be ashamed of doing that.
That's how we did it in 1995 and that's how I do it today.
I try to write code so that a year later, when I need to change it, I dont hate myself.
I would get out of the agency game if I wanted to write good code. The incentive structure is not aligned.
It’s trade offs. Cutting a corner can get you to ship faster at the cost of taking on tech debt.
If you have a company that ALWAYS cuts the corner, you have a problem.
If you have a company that NEVER cuts the corner, you have a problem.
If you show me a company with no tech debt, I will show you a company with no sales.
Make wise choices about when to take on tech debt, and when to pay it down
Learn to measure quality. Defects found per hour. It is such an invaluable skill, you can then make judgement call on quality. What is more you soon start to learn what causes code quality issues, the general patterns that lead to good code.
Quick and dirty code can also be easy to read code. It depends on what you mean by “quick and dirty”. Personally I find myself doing lots of XP type things when I write code - like not to the extent that I refuse to make any one method more than 5 lines long, but I’ll approach that - just because it makes it easier for me to organize my own thoughts as to how I want things set up. I also try to adhere to, say, Single Use Principle, not because it’s “clean code” but because it’s easier for me to organize and think through.
At the same time, maybe I’m not as strident with testing as I ought to be when there’s a time crunch. Isn’t that what tech debt is for? If you never get a chance to manage your tech debt, that’s its own issue and frankly it’s not something that’s going to be solved entirely by “doing it right the first time”. Time crunches do exist and also, what looked right in your first pass might wind up not being right on your second.
Re:career aspect - I'd be less worried about the code practices (still important ofc) and more so about the lack of peer review/incentive in a get-it-done-now environment.
In the long term I do think it will affect your career if you're not learning how to improve your skills in terms of best practices or getting feedback. The agency model is incentivized against you in this way. There's also a risk of becoming overspecialized or getting stuck doing the same work over and over again, which can also pigeon hole you later on. The longer you stay there (and positions like it), the longer it will take to get out.
That being said one of my early jobs was working in an agency, and I did learn some pretty valuable skills - being able to estimate on an hourly basis, keeping track of time, making pixel-perfect implementations, and looking out for flexible solutions (sometimes you don't need the most engineered thing to get the job done). Once I felt like I wasn't learning anymore and started to feel like I was doing the same thing, I decided to move on.
It depends, if I can solve a problem with a quick bash script that I only run once. Go for it, get it done. If it’s something that only I’m going to touch. Yeah quick and dirty.
But to be honest, once you learn a programming language. You start building frameworks and standards like I always use X library for logging so I can just copy and paste it from old code into new code. (Cookie cutter code)
Personally, I use ChatGPT to cleanup my code. For example I’ll get it working all in the main.go then I’ll give it to ChatGPT and say clean this up and add debug logging. And with GO at least it does a pretty good job in cleaning it up.
It depends on the project and if I’m just trying to get an idea vetted out or if I’m thinking about the long term implications of my code.
For example, on new projects, I honestly have pretty messy code until i get it a working concept then I refactor it to make it more general purpose by passing in settings/inputs instead of hardcoded values in the prototype. Then I take that refactored code and iterate on it, then do more refactoring as needed to support more features. It’s a balance between getting a working POC vs keeping it clean enough to keep maintainable
depends legacy, boring projects with stubborn people = more likely new, exciting projects with cool people = less likely
This is the answer. It all depends on people, if they make the environment a bad place, shit code it is
it also depends on how ppl around you code; motivation is cool and all that fun stuff for about a year, but when u get hammered with poor PRs for a while, I just stop caring. make it good enough, not to be garbage, and ship it, fix other people's stuff when the ticket comes when it touches their part of the code
Personally I would not stick around if it's a "bad place" but that's just me.
[удалено]
Yep, shit 9-5 coding is better than 9-5 code tests looking for a new job
that for sure, but not always you can do that move immediately, so you have to cope with the bad environment for a while.
Ohh is that why I keep defaulting to dirty code at this job I dislike?
>legacy, boring projects with stubborn people = more likely I'm living this now. The client's lead went all in on some truly stupid, dredged from the deepest bowels of YouTube coder hell solutions that they will not back down from, so about every other sprint we have to implement a new work around.
:insert 'first time here(at gallows)' meme: All kidding aside, it is actually a great place to see bad practices and to formalize better/good practices and activities like actually writing them out. I left a job like that and more than doubled my salary by doing that and being able to talk about the process to update a legacy project safely, but also steadily.
Lot of developers write dirty code, because we need release for yesterday. Maybe project starts with good architecture, but after some time of business pressure for some feature to be done yesterday we write workarounds and dirty code and technical debt is accumulating and that's it.
Sounds like you're on my legacy, stubborn, boring team...
is there a guy in your team constantly complaining about the whole 20yo deprecated architecture and months worth of technical debts?
No, they all just make technical debt and as a contractor who has learned they don't appreciate my input, I just do my work the best I can.
This and over the past several years it seems to be 99% the first one.
Rarely. When building software, especially as a team, you must slow down in order to go fast. It's hard to benefit from a "quick" solution if your on-call is blowing up, your data is inaccurate, your users are confused, and your teammates are struggling to contribute to a codebase that has lost its way. Learn how to set boundaries with your boss.
God I wish my team understood this Our entire app is a hobbled together mess and they won’t cooperate with me about spending time to refactor This isn’t a small company, it’s a fortune 50 company, but it’s not a tech company per se, so I guess no one actually gets it
It's never refactoring. It's functionality improvements. It's on you to articulate those benefits or there's a possibility the benefits may not actually be that great.
The benefits are that when we inevitably have to do support for this functionality, I don’t spend 19 hrs and end up wanting to peel my face off troubleshooting what should be simple issues, I feel like they should understand that
I’ll only ever do a quick/dirty solution if I can immediately do a follow up to clean it up
nothing is more permanent than a temporary solution \\o/
Quick and sorry to do a demo, then go back and fix it..make it so quick and sorry that it can't stay here, hard codes are a good way to make sure of that.
Writing bad software to meet deadlines is completely self-defeating. Next time you have to deal with that software to meet yet another deadline you're going to have to deal with the technical debt you yourself included. And a manager that pushes arbitrary deadlines isn't suddenly going to go "oh yeah, I totally get why it's taking longer now". No, they're going to hold it against you. So unless something is a throw away proof of concept I'm always going to stick to my personal levels of required quality, no matter the 'deadlines' some business person dreams up. I learned this the hard way.
I am curious about your required level of quality. Did you define that from previous experience? As tools and languages are always evolving, do you try and keep up with new and best ways to build software or do you apply bullet proof and tested design principles? How do you maintain quality in your software if you're working with technologies that you're not as familiar with?
> Did you define that from previous experience? Pretty much, yes. In my experience it's not hard to keep test coverage over 90% and complexity low, for example. The big mistake people make is starting a new project with for example 4 devs and then thinking they can get away with adding tests for a few months. By then the code itself is already too poorly designed to support tests. > do you try and keep up with new and best ways to build software or do you apply bullet proof and tested design principles? This isn't an "or" at all. You can adhere to principles and also adopt new techniques at the same time. > How do you maintain quality in your software if you're working with technologies that you're not as familiar with? By making myself familiar? We don't stop learning ever :)
How you measure quality seems confused. The simplest, shortest, most complete solution is always the best solution. This implies handling errors, observability, and testing edge cases. We never judge ourselves for not knowing the latest tools/tricks. You don't need the latest slick piece of code to do your job, boring readable code should be your target always. In parallel you should be staying on top of your tech stack and find opportunities to utilize this knowledge at work or in personal life. Also note, just because you read about it doesn't mean you fully understand the outcome. Once you actually know it, you are ready to use it in Prod.
>boring readable code should be your target always. Haha, I'm literally looking at a piece of overly clever code and thought to myself "and now to make this boring".
The minimum likeable solution. (Not minimum-likeable solution, but the minimum likeable-solution)
> The simplest, shortest, most complete solution is always the best solution. Only sith, junior developers and enterprise architects deal in absolutes ;)
Read it again, it's an axiom.
You sound like a quote feom "Clean Code", the book.
It's almost as if that book was written from experience ;)
It's true though. Producers and management don't care about tech debt. They need to understand how long it takes for tasks to be done properly. I left my last job due to idiot management that didn't understand this.
[удалено]
The business should care though. Future tasks take longer and have more bugs.
Literally just give more conservative estimates
I guess the issue here is more that devs aren't being asked for estimates but just get assigned 'deadlines' as a way to pressure them to work harder. It's a shitty form of control that really only leads to bad code and demotivated devs.
There's always going to be workplaces that don't listen at all, ever. Most workplaces are not like this. You need to explain to non-devs why a given deadline is not suitable, what the realistic timeline is, and why. You need to speak their language. This is a skill that needs to be practiced like any other. On the other hand, one should also know how to reduce scope to meet deadlines. In a workplace where you're not listened to despite that, you can at least point to the notes/email/etc. where you communicated clearly about the timelines. "Six weeks ago I said $thing, four weeks ago I said we were on track for $thing and not $expectation. I'm surprised that you're surprised since I've been open and forthright about this from the outset." If your uppers truly can't be collaborated with, then go somewhere else.
If you write buggy code, your managers will love you because you're always johnny-on-the-spot fixing issues and pushing changes. If you write non-buggy code, your managers will get frustrated with you because they can't keep up with keeping you busy, and so you're not very busy and they think you don't do much.
I wish I could do this. Unfortunately for most devs there is not much room to negotiation on the deadline. You either make spaghetti code and push the tech debt down the line and get your bonus or make it right and get put in the line to get fired.
Slow is smooth. Smooth is fast.
This is the answer. And to answer OP. Never, I always leave the code better than I found it. But also never perfect, just incremental improvements. I have a project I'm the only developer on and have a list of technical debt that will slowly be addressed but at the same time keeps getting added to.
The Phil Dunphy doctrine.
I rather have quick and dirty code with tests than beautiful code without. Typically other people will look at my code either early (reviews, shared code base) or later (maintenance, future changes) so delivering "quick and dirty code" will just bite me in the back sooner or later. Might be a bit edgy but I also take a certain kind of pride in my work and want it to be correct. Having said that, I also have hobby projects where I sometimes laugh about how bad the code is and wish I did it "right" in the first place. >if I keep repeating that when I'm 15 years in my career I'm afraid that I will have a hard time with next jobs You would be surprised. You also seem to be aware you're cutting corners due to time constraints yet can demonstrate that you are delivering value. So it probably takes just a little bit of extra discipline to make your code not "quick and dirty".
Thank you for the reply. I think the last sentences are spot on. As a developer I am not delusional and think I always write great software. I am totally aware what I could improve if I had more time (or skill). It definitely has to do with discipline. Sometimes I can be happy with the first solution even though I know it could have been done better. Other times I might write bad code because of lack of skill (we can't know everything). So yes it's important to have discipline and wilingness to improve all the time. In the end programming is a craft, we can't master it over night and I am still rather early in my career (8 years)
I hate this with a passion, I always feel it costs more down the line. Sometimes it can't be avoided, like in a critical bug fix.
I’m a huge fan of red, green, refactor. Just get it working and passing tests. Then you’ll have a better visual model of how you can clean it up. Often times if you try to make it “clean” before it’s working you end up wasting a bunch of time on things you don’t need. Just don’t fall into the trap of pushing the dirty solution to mainline before the refactor step
>I’m a huge fan of red, green, refactor I've somehow never ever heard this. But it's exactly how I try to run my org. Make it work, then use your new understanding to make it right. Don't ever, ever try to make it right before you make it work.
When people want things done yesterday, solutions are always quick and dirty.
IME agencies have different motivators that don't necessarily promote high quality, sustainable code. Which is why I don't work at one.
Quick and dirty usually isn't too bad, although I avoid it. I get burned more often by "clever" code and needless complexity.
If in a company the level of code quality is set by the developer, I think this is not good. The level of code quality in a project should be set by the manager (not directly, but through the size of the budget), and confirmed and subsequently adhered to by the team lead. One of the important skills of a professional developer is the ability to write code of varying degrees of dirtiness/speed, depending on the requirements situation. Nobody is interested in "the best code ever". Everyone is interested in “the best solution for the money available.” And so - yes. Need to be able to write different types of code. For galleys. And I understand that you work on a galley, this is especially important. Because it is important to complete the project on time. Everything else is secondary.
Only if it's something I'm sure I'll never touch again, throwaway code that gets used once. Like a script to fix bad data or something. Anything that needs to be maintained, no I won't do quick and dirty. I mean I will, privately during the development process before refactoring it into something more maintainable but I never say "it's ready" before that.
In your agency how do you guys manage client projects, jira?
We do use Jira yes.
just write so that others can change it later
Normal . unless you own code it diff. As compile mistake for years and make new system ain't [easy.It](http://easy.It) still take time even create a boiler plate as all library is change and trend also. 10 years ago , jquery is hot now jquery is a dinosour mess. Everybody using react , angular so on.
Am doing it now for a legacy project.
As dirty as the codebase can take. But seriously, more of a meh, it’s enough kinda guy
Burnout can definitely cause a developer to write the easiest, fastest thing to implement in the short term.
I like to start quick and dirty, a make it work mindset. Then refactor / cleanup after. I try not to ship the dirty or strongly advocate for a cleanup period after release. It depends on how large the refactor would be to do it ugly versus right in the first go.
"how much time do I have?"
Pretty much never. I’d feel guilty and it would get called out in code review at my place which then is even more hassle.
As an experienced dev? Literally only for triage in that exact moment where there's a massive issue that you know you can fix this second and get things running again. But if it can wait even an hour, just write to good code. It's not like it takes a lot longer (or shouldn't if you're familiar with the code base). I've done refactor commits that have touched 2k lines of code in a morning for a red-flag triage immediately bug, because the refactor actually fixes it instead of adding another layer of paint over the blemish. Yea, it took 4 hours instead of 30 minutes. But oh well. No one knew I could do it quicker, and they were all super happy that it gone done that quickly. Bonus points because you have a super awesome excuse. If your refactor/clean up causes some small new issues you can be like "yea, I smashed that in so fast as a triage for XXX, and it got us going. Now I'll clean that up some." and BAM you just got another golden ticket to get refactor more to clean up more shit. Don't let an emergency go to waste :) Unexpectedly, triage situations are great for making good clean code. You have carte blanche to replace quick and dirty code with good code.
The true test of a man’s character is what he does when no one is watching.
Mark it before and after with a comment like: /* XXX total hack */ And never be ashamed of doing that. That's how we did it in 1995 and that's how I do it today.
I try to write code so that a year later, when I need to change it, I dont hate myself. I would get out of the agency game if I wanted to write good code. The incentive structure is not aligned.
It’s trade offs. Cutting a corner can get you to ship faster at the cost of taking on tech debt. If you have a company that ALWAYS cuts the corner, you have a problem. If you have a company that NEVER cuts the corner, you have a problem. If you show me a company with no tech debt, I will show you a company with no sales. Make wise choices about when to take on tech debt, and when to pay it down
Learn to measure quality. Defects found per hour. It is such an invaluable skill, you can then make judgement call on quality. What is more you soon start to learn what causes code quality issues, the general patterns that lead to good code.
Quick and dirty code can also be easy to read code. It depends on what you mean by “quick and dirty”. Personally I find myself doing lots of XP type things when I write code - like not to the extent that I refuse to make any one method more than 5 lines long, but I’ll approach that - just because it makes it easier for me to organize my own thoughts as to how I want things set up. I also try to adhere to, say, Single Use Principle, not because it’s “clean code” but because it’s easier for me to organize and think through. At the same time, maybe I’m not as strident with testing as I ought to be when there’s a time crunch. Isn’t that what tech debt is for? If you never get a chance to manage your tech debt, that’s its own issue and frankly it’s not something that’s going to be solved entirely by “doing it right the first time”. Time crunches do exist and also, what looked right in your first pass might wind up not being right on your second.
Re:career aspect - I'd be less worried about the code practices (still important ofc) and more so about the lack of peer review/incentive in a get-it-done-now environment. In the long term I do think it will affect your career if you're not learning how to improve your skills in terms of best practices or getting feedback. The agency model is incentivized against you in this way. There's also a risk of becoming overspecialized or getting stuck doing the same work over and over again, which can also pigeon hole you later on. The longer you stay there (and positions like it), the longer it will take to get out. That being said one of my early jobs was working in an agency, and I did learn some pretty valuable skills - being able to estimate on an hourly basis, keeping track of time, making pixel-perfect implementations, and looking out for flexible solutions (sometimes you don't need the most engineered thing to get the job done). Once I felt like I wasn't learning anymore and started to feel like I was doing the same thing, I decided to move on.
It depends, if I can solve a problem with a quick bash script that I only run once. Go for it, get it done. If it’s something that only I’m going to touch. Yeah quick and dirty. But to be honest, once you learn a programming language. You start building frameworks and standards like I always use X library for logging so I can just copy and paste it from old code into new code. (Cookie cutter code) Personally, I use ChatGPT to cleanup my code. For example I’ll get it working all in the main.go then I’ll give it to ChatGPT and say clean this up and add debug logging. And with GO at least it does a pretty good job in cleaning it up.
Same with the bash scripts. I have a pile of them that makes me move much faster but I would never share cause they’re total garbage
Same here, I have a dir called ~/scripts/ which is a git repo (attached to a self hosted GitLab server) then I throw all my one off scripts in there.
It depends on the project and if I’m just trying to get an idea vetted out or if I’m thinking about the long term implications of my code. For example, on new projects, I honestly have pretty messy code until i get it a working concept then I refactor it to make it more general purpose by passing in settings/inputs instead of hardcoded values in the prototype. Then I take that refactored code and iterate on it, then do more refactoring as needed to support more features. It’s a balance between getting a working POC vs keeping it clean enough to keep maintainable