Awesome list. While I know I'm not the only one who also does these things, it's good to see these sorts of things brought out in the public from this perspective. Yes, we're all human, and we all know we can do better. Thanks for being honest in public.

Here's something I see with well informed beginners: They have to do everything perfect all the time.

No you don't.

Technical debt is like actual debt: It's bad to let it pile up, but it can give you powerful leverage. Don't quite know how to do something? Well, if you don't even know exactly what it is, it's going to be much harder to write it in an elegant way from the get-go! Write it so it works at all, then refactor your way out of stupid architecture.

I did this the other day, even though I already had an architecture designed, and what I came up with was even better than what I had thought of. The code will talk to you. There may well be CodeSmells. By playing with code, you can often see EmergentDesign.

http://c2.com/cgi/wiki?CodeSmell

http://c2.com/cgi/wiki?EmergentDesign

Technical debt isn't a sin. It's a tool, but it's a tool that can bite you, so use it wisely! (Analogy: It's the shop owner who should decide when to get a loan to buy inventory, Not The Customer!)

I like the acknowledgement that we aren't all perfect—not even as close to perfect as we tell ourselves and others we are. It actually reminds me of this collection of Isaac Asimov stories I've been reading called The Edge of Tomorrow, with each essay or story featuring a scientist. Asimov denies a deliberate connecting theme, but what I keep noticing is how scientists are just humans too; they aren't these ultra-intelligent, purely rational subspecies. Similarly, programmers may have an understanding of computers that others lack, but we are just as prone to imperfections, mistakes, and inefficiencies even though we work in our own domain of expertise. Acknowledging that seems more useful and honest (to me) than claiming that a certain methodology will make you capable of coding the perfect program the first time around or something.

Point number 4, "I regularly succumb to the pressure of my todo list, and let myself push quick fixes out the door when I feel overwhelmed." isn't necessarily bad though.

While I'm not the biggest fan of todo lists, well planned and well organized lists do actually help me get things done in a clear and focused manner. If a deadline for a project is looming over my head and I have a handy, well planned todo list for said project handy, I am going to be pushing lots of quick fixes that let me cross things off of my list.

That being said, perhaps this only works well for me because I do take some time prior to writing/adding to the list and attempt to think before I make a list and as such, things turn out better.

I do a lot of these things. It's called taking in technical debt. Debt has it's place in this world, especially in startups.

It sounds like he's shipping, which means he's doing it right.

All of life is trade-offs, no?

This list is inevitable I think for anyone who is trying to ship or has some sort of deadline. The most important thing I find in maintaining large code bases is to vigilantly keep the broken window theory in mind (http://en.wikipedia.org/wiki/Broken_windows_theory). It takes some discipline to actually go back and fix things that are broken, but it does help to avoid longer term software rot.

No codebase is perfect at any single given point in time, but when you see a broken window, fix it.

http://pragprog.com/the-pragmatic-programmer/extracts/softwa...

I suggest you read this book: http://www.amazon.com/The-Clean-Coder-Professional-Programme...

There's a social factor to being a professional too; it's not just raw programming skill or experience.

Conclusion feels like meaningless fluff. There are people who genuinely don't realise that test first is better; it's worth sharing the fact that it is. "Doing it wrong" is just a buzzphrase at this point.

Feature creep - that is what I'm guilty of.