this post was submitted on 30 Aug 2024
6 points (87.5% liked)

Coding Cafe

60 readers
1 users here now

A community for all programmers

founded 2 months ago
MODERATORS
[email protected]
6
What Differentiates a Good Developer From a Bad Developer? (medium.com)
submitted 2 months ago by [email protected] to c/[email protected]
4 comments fedilink hide all child comments
top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 8 points 2 months ago

Some ok takes here and some weird ones. I understand this is supposed to be a simply written article but I think "clean" and "messy" are way too reductive in this type of discussion without more context.

While I do think many good developers are passionate, it does not take passion to adhere to good practices. I don't expect a bridge designer to be passionate about bridges, I expect them to follow best practices and a good bridge will follow.

Accurate estimates are only possible when tasks are well defined and well scoped. A bad developer will still give you an estimate on a nebulous task, a good developer will tell you there needs to be more investigation.

All code will have bugs, a good developer isn't someone who never makes bugs. This is why testable code is important.

[–] bluetardis 4 points 2 months ago

Most of the “qualities of a bad developer” are imposed by their management.

[–] [email protected] 4 points 2 months ago (1 children)

Oooh. I know this one. Testing their code rather than chucking it over the fence and crossing their fingers. Of course that's management's fault.

[–] [email protected] 1 points 2 months ago

Yes it’s managements fault. Get asked to rapidly prototype a feature/service. 80% chance the lift is too big, won’t meet requirements, is literally impossible without a quantum computer and 5.2 gig watts of power, not wasting time writing tests for a prototype that will most likely be trashed. When the 20% case happens, scope writing tests, but the customer has already seen the MVP work and is clamoring to get it out now! I explain we need unit and integration testing, proper CI/CD, need to implement logging and Datadog integration, build in Okta integration and with testing, etc.. you get the point, these are necessary and non-trivial task, but most don’t understand why when you just had a working prototype. Customer screams at your manager to deploy what you have now, bugs inevitably introduced, you spend time debugging issues that would have been caught with unit/integration testing or just a little more time refining your service, don’t have time to iterate or improve because of fixing bugs. The cycle continues…