| This is all assuming that a coders job is to just code...and make code better, which IMO it rarely is. Honestly, the most lucrative code bases I've worked on are generally considered terrible, annoying, incorrect, frustrating but they are functional. The most recent example I can think of was a startup I worked which sold for billions of USD, it was considered by everyone as terrible. A large part of our job was understanding complex requirements and integrating with other companies poorly implemented APIs, wrangling XML etc, so we didn't code a lot, we planned a lot. Fundamentally I think we're just talking about different aspect of the job and we disagree that being a "coder" is about lines of code. In my current job, I've been helping my team, especially new comers understand complex systems and business logic which we didn't have a lot of time to document because of the insane growth our company went through and the insane amount of stress we were under to deal with demand with only 2 engineers. I've not written more than 20 lines of code in 4 weeks, really just mentored and guided people, should I be fired? |
I also haven't reviewed your code!
But if you are specifically writing code that has the kind of errors that I describe, or are continuing to "add fuel to the fire," I would set very clear standards and expect that you meet them. I understand that you can't fix every problem overnight, and that you have to pick and choose the things you fix carefully.
But if you continued to, for example, write code that was vulnerable to SQL injection, after I made it clear that this was no longer acceptable, yes I would fire you.
Edit: Likewise, if you were reviewing someone else's code and allowed SQL injection, I would consider you "the source of the problem" and fire you. If your "20 lines of code this month" contained SQL injection, I would wonder why, after setting a clear expectation that SQL injection isn't allowed, you couldn't take the extra five minutes to write parameterized SQL, and then and fire you.