Here I'm capturing some unedited thoughts on what constitutes good software development based on 10+ years of experience.

First, every engineer needs to read Clean Code. It took several years of writing software the wrong way to learn that good code is simple and sometimes unintuitively verbose. Some of my learnings were rooted in needing to set up ridiculous stateful preconditions in MVC web frameworks. Just a simple code-refresh-click form cycle that takes more than a couple seconds is a waste of time. I took in other learnings about writing clean code from conference talks on refactoring and Behavior Driven Development (BDD).

The real lesson of BDD came by accident with the benefit of Rails' IRB console. I found myself writing simpler and simpler classes and methods just so that I could easily test them in an interactive console. BDD was essentially what I already knew about unit testing (write the test first) plus writing code that's easily testable. The frameworks that BDD provides, especially around DSLs, is all icing on the cake.

I have yet to work in an environment that has embraced BDD, but the development patterns have stuck.

Second, the old adage that "you're not writing this code for today, but for yourself 3 months from now" is essential. This ranges from comments in the right places (sometimes with examples) to expressive naming and clear commit messages. You, or the teammate who is making changes, will appreciate it. Especially when they're sifting through a lengthy git history.

Third, I've learned never to release software with some warts and say to myself "oh, I'll get in there next sprint and do a little 'off the clock' cleanup". It never happens. You're off to the next big challenge and those warts are likely there to stay. Even worse is if someone else finds, and has to work with, those warts.

Fourth, before even thinking of putting bits to file, put some time into thinking about the problem. What are the components? What are the interfaces? Where in the stack does logic go? Write some sketches and a few basic UML diagrams. Once the problem is solved on paper, writing out the code is simply transferring what I know to a repository.

Most importantly, software is merely one tool to providing business value. It's a work of craftsmanship, but unless a personal project, it's not going to be perfect. A balance has to be maintained between correctness and moving business forward. If I find ugliness but don't have time to fix, I'll comment, note it in wikis, and update related tickets for opportunistic improvements and refactors.