Do you worry about the quality of code?

For me, this is something that has just gotten better with experience and practice.

Of course, we all start out with a clear and rigid vision about how the code should be - you use good design patterns, you let your data dictate the flow of your code and inevitably, some scenario comes up that doesn't play into your structure well and you concede a hack. Then a couple more. But with experience comes being able to identify areas that are more likely to attract smelly code and thus you are able to prepare in advance.

One of the paradigms that I am always reiterating to my team is that their code only needs to be 'good enough' and of course, this is relating to productivity. It doesn't need to be the shiniest example of a memento implementation I ever saw - first and foremost, it needs to work. And it needs to work when I need it to work, not 2 weeks after because you just had to refactor it just one more time. This is the reality of being a professional developer, working with customers.

I'd assert that if you're a great developer, then the code you write quickly is not worse than the code you write slowly. For every problem there is a perfect way to solve it, and every hack and other kind of ugliness your code acquires increases the distance of your code from the ideal one.

If you write code too fast it gets those imperfections because you are not yet good enough. But you are on your way to improve since you are able to reflect on your work and see how it can be better.

A good way to get better is to write code as slowly as possible. Take your time and focus on making every detail as good as you can. It will take time but as long as you do it slowly enough you will learn a lot. You will get better as your "slow and perfect" time improves and your brain adapts. You will improve much faster than in "fast and sloppy" mode which trains your brain to not mind the ugliness.

I absolutely think about clean and quality code. The easiest way to do it, in my opinion, is to write the most customizable and modular code from the beginning. Because, inevitably, mid-project you'll want to use something you've already written with a slight twist or use a class somewhere else where you didn't know you'd need it - but now you can just drop that sucker in and spend no time making a totally new class for something so it doesn't break something you've made earlier. It really doesn't take too much extra time to do this either, especially if you're constantly thinking like that - future proofing your code for the unknowable and very changeable design requirements. Loosely sticking to MVC has greatly improved my app coding. Here's how I set it up:

* Controllers

* Data Objects

* Utility UI functions (making shadows, or anything that can happen anywhere)

* Data Managers (sometimes Singletons)

* Web Services

If I start with this model in my head, the code is self organizing because I'm not writing data parsing in a controller because I KNOW with 99% certainty that I'm going to parse something later in another controller or something even higher is going to handle that data at some point in the future.

This kind of abstraction is how I do it currently, and I've only gotten here through experience, and I'm sure that I'll find even better ways as I continue to code into the future (I'm already thinking of base iOS project templates that contain that structure already).

I am currently a graduate student and I can say that I, without a doubt, worry about the quality of my code. I worry about this because I have to rely on other student-written code that often does not perform as advertised. I refactor both my code, and code written by other students very frequently even though the code is really only "proof of concept" because I need to refactor other people's code to get mine to work. I cannot stress enough how important it is to refactor (and document) code.

The main thing I do is try to implement very thorough unit tests. I find that the act of writing the tests helps me think through the interface to the code, which in turn helps me isolate the caller from implementation details. It also helps make sure an individual module doesn't try to do too much or too little-- the unit test will start to feel "baggy" in the first case, and will look pretty thin in the other.

If you haven't read "Working Effectively with Legacy Code" by Michael Feathers, I would strongly recommend it. The book officially is about how you get existing code under test, but its techniques orient around moving the code to a better organization.

The book "Large Scale C++ Software Design" by Lakos lists some actual, computable, metrics for assessing how interconnected your code is (and hence how hard to change). Never having used those metrics, I can't recommend them one way or the other; I just know they exist.

Code quality means a lot in my opinion. A nicely structured and organized code not only shows its programmers' expert skills but makes it easier (and faster!) to modify or extend the present functionalities. Also if you care about code quality it really helps you to develop your skills.

As others stated it is needed to start a project in a way that you care about the quality. Even when there have not been a single line written. Also being agile also means that you refactor and redesign from time to time when it is needed.

I always check my code after implementing a functionality. If it is needed, I refactor my code. Also there are numerous tools to check code quality (e.g. Sonar). A very good approach is to have code reviews as well if you can.

There is a very nice book in this topic which the others have not mentioned, but if you are interested I advise to read it: Clean Code by Robert C. Martin.

If I'm working on a homework assignment, yes I go over it a few times and clean it up.

If I'm working on our startup, I often google / copy+paste, whatever gets the job done. If I find myself struggling to make it work how I want or I'm spending more time fighting with the code than I'd prefer, I go back and refactor the code.

it's a constant battle. sometimes you have to compromise, sometimes you can claw some time back to fix up previous compromises.

finding the right balance pretty much defines what being a good professional software engineer is, imho.

I do first code. Then refactor. I cannot do clean, perfect code since there's always pressure from management. i try to refactor once I have everything working.