this post was submitted on 03 Dec 2023
-23 points (17.1% liked)

Programming

17530 readers
257 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

“I’m not a great programmer; I’m just a good programmer with great habits.” – Kent Beck.

So, what sets apart an efficient developer? You’ll be surprised—it’s your key traits and habits.

In every R&D team, there’s that standout individual, the rockstar everyone seeks advice from. Typically, these programmers are humble and never label themselves as wizards or high performers and they usually walk bare feet in the office. Ever wondered how these top developers distinguish themselves?

We’ve talked with some leading Engineers and compiled a list of the most essential traits and habits to guide you on your journey to becoming a more efficient developer.

you are viewing a single comment's thread
view the rest of the comments
[–] DrDeadCrash 2 points 11 months ago* (last edited 11 months ago)

So, the question is, how do you deliver better code faster?

I think there question needs to be: how do we convince people that it's "worth it" to pay for better code?

I get it, we all want to do our jobs well and excel in the craft. The problem i see here is that the stated need for cleanup, refactoring and documentation is immediately followed with a 'but'. But there is no but, imo.

Code that "works" isn't good enough, and we need a full stop right there and heads around the table nodding up and down in unison. But they'll take the inferior POC build every time over investing in a "good" solution that incorporates lessons learned. Next they complain that it can't be modified easily ("but, it's just a simple change!"), and bemoan the state of software development.