4 ms·
No, because the quality of the existing code isn't what affects my interest in the job. The vast majority of software out there has mediocre structure at best.
by gshdg 7y ago
No, because the quality of the existing code isn't what affects my interest in the job. The vast majority of software out there has mediocre structure at best. Your responsibility is to improve it gradually, leaving each function or module you touch a little bit better than you found it.
The jobs I've enjoyed the most and learned the most from were incidentally the ones with the worst codebases.
That said, it's probable that there's a certain degree of awful that it's simply impossible to work productively with. As a hiring manager, I wouldn't consider it unusual or a red flag for a developer to ask to see the codebase; and every project has at least some code that isn't too sensitive to share (well, there are probably some exceptions in regulated industries).
If a developer doesn't have the maturity to be willing to work with a codebase that's six years old, where the earliest layers were quick-and-dirty proofs of concept developed without automated testing just to get a startup off the ground, and the latest are better but still flawed, then they're a poor fit here anyway. We need developers who understand that the code exists to serve the business and not for its own sake.
- world32 7y ago> We need developers who understand that the code exists to serve the business and not for its own sake. You're absolutely right about that - there is always a balance to be achieved between delivering a feature/product on time and writing maintainable / "good" code. What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable. Nothing is perfect but in my experience the difference between working with a well thought-out and architected codebase and something that has been hacked together as proof-of-concept is immense. Fewer bugs, fewer security vulnerabilities, the ability to deliver features faster etc. I don't think that code quality is just something for developers to pat themselves on the back for - it genuinely effects business outcomes.
- duncan-donuts 7y ago> What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable. Bingo. Bad code bases are fine as long as people agree that it needs to be better. I’ve worked on bad code bases that people just do the bare minimum, quick and dirty bull shit they’ve always done, and it’s absolute misery.
- Aeolun 7y ago> I’ve worked on bad code bases that people just do the bare minimum, quick and dirty bull shit they’ve always done, and it’s absolute misery. Those people do not realize anything is even wrong. :(
- deleted 7y ago[deleted]
- gitgud 7y ago> leaving each function or module you touch a little bit better than you found it. This is some of the best advice you can give a developer I think it's known as; The Boy Scouts rule: “Always leave the campground cleaner than you found it”. Some people I've worked with seem to miss the importance of this...
- Aeolun 7y agoSometimes this has been really hard when the campground was already spotless.
- yen223 7y agoThe problem is that someone's definition of "cleaner" can be wildly different from yours. Sometimes even justifiably so.
- gitgud 7y agoYes people can disagree on what "cleaner" code means. But generally people can agree on badly designed code eg; bad naming, deeply nested logic, bad structure, tight coupling, no separation of concerns...
- JohnFen 7y agoThat's the reason that all companies should have in-house coding standards. There are many different legitimate variations on "clean code", so the important thing is that one variation is chosen and used consistently by all devs. Which variation is chosen is less important.