There is a difference between perfect code, nasty code, and ok code. It doesn't take much to turn a nasty patch into an ok one. Around 2002 or so I realized that all of my open source code could one day be read by someone looking to hire me. It really made me change my coding style. Taking the extra thirty seconds to review your change, make a better commit message, follow a common code style, better variable and function names, make a README (back before github) etc. The more I did this the more I benefited from it myself. I caught mistakes, it was easier to go back in the history of commits etc. In essence I became a better developer for it.
tldr; Always assume someone will be reading your code in the future for a job hire. If not for them, for you as it will make your code better.
> tldr; Always assume someone will be reading your code in the future for a job hire.
I agree that what you suggest in terms of improvements in how you code is beneficial--especially if it's a permanent change in your coding style. I think permanent changes in coding style like that happen when we realise it's actually beneficial to us even before it helps someone else.
At the same time I posit that there is much useful/functional (albeit ugly) code sitting trapped on hard-drives around the world because the developer is concerned a future employer/client might judge them for it if it were released.
While this sort of filtering by prospective employer/client may well happen, I think the average developer concerned about such things has a much higher standard for work than needed.
I've tried to adjust my thinking to "Well, it works for me, that means it might be useful to someone else, so I'll put it up there. If some future employer/client can't see that it's a quick hack and not representative of my daily work, well, that probably says more about them."
I'd rather find your 10-line hack to get that obscure API working and build on it, than nothing at all.
in my opinion it should be tldr; Always assume someone will be reading your code Wether it's a potential employer or an open source contributor, those are always good practices.
Uh, what? Forget about potential employers or open source contributors. You will be spending a lot more time reading your code than you'll spend writing it. So making things readable makes things easy for you.
tldr; Always assume someone will be reading your code in the future for a job hire. If not for them, for you as it will make your code better.