[bamboozled]

No you can't because being a good developer isn't always about smashing out code, I've easily spent 30 days with great developers talking about planning and implementation before much code is written.

Hopefully it's not you who is the mediocre developer?

[gwbas1c]

Err, there are very obvious "beginner" mistakes that don't have to do with "smashing" out code:

Things like: State in strings instead of properly defined enums / data structures. Magic numbers instead of constants. Dangerous error handling. Compiler warnings. Missing or incomplete input checking. Anything vulnerable to SQL injection, or similar. Significant copy and paste within the same codebase.

When a developer with more than a few years experience writes code like that, (except in throwaway situations,) then there's a clear problem.

More subjective signs of a poor coder are: Super long methods, (or too many sort methods.) Passing around a single value but always picking a new variable name. Inconsistent naming conventions. Sleep statements to fix race conditions. Unnecessary special cases. Incorrectly using an ORM. Code that is many orders of magnitude slower than need be. (IE, sucking the entire DB into ram for just one value.)

Some language specific warning signs: Lots of "unsafe" (pointers) in C#. Lots of unwarps in Rust. Bounds issues is c/c++.

[bamboozled]

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?

[gwbas1c]

I would probably say that your role isn't a "coder," but is more of a team lead or manager without the title. Other than that, I don't understand your situation well enough.

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.

[gwbas1c]

To add to my reply from a few hours ago: I'm currently fixing a bug like what you describe.

The code is C# and involves heavy reflection; but if the person who wrote it used a simple lambda, it would be fine and easier to maintain.

In such a situation I'd make it clear that reflection is inappropriate in this situation. If the developer continued to use reflection when simple lambda statements were appropriate, I would make moves to fire the developer.

Again, I would set clear expectations first.