Code Quality and Passion, User-Centric, Continuous Learning, Accurate Estimates and Communication
  • TheOneCurly@lemm.eeEnglish
    8·
    3 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.

  • str82L @lemmy.worldEnglish
    4·
    3 months ago

    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.

    • spacecadet@lemm.eeEnglish
      1·
      3 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…