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.

Fair enough. I agree that the code has to be working but sometimes, even after laying down the guidelines on how to write code a better way to structure out, things go out of hands with multiple contributors. In my opinion, the solution to this problem is to refactor the code as soon as the code is checked in. Not necessarily refactoring the whole code, but to make it conform to the existing design and structure.

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'd have to disagree there. No matter how good a developer you are, if you're in a rush, you're not going to output the same quality. There's always going to thousands of decisions in a programmers head where they could take time to make something more efficient. If time is the top priority, then well designed code isn't.

And for what it's worth, I don't think that code needs to be perfect. If you're testing out an idea, your code may just need to be good enough to test the idea. Then when the idea has been validated, you can worry about perfecting the code.

Well I disagree with you. :) Being in a rush almost by definition means that you have to perform faster than you're capable of. But the point is that you can push your limit on what "being in a rush" means by practicing. A few hours might be impossibly rushed for one programmer while it is ample time for another. Furthermore the more you train yourself on writing good code, the less of a speed advantage it is to write bad code.

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.

Working across teams and developers is one more reason to worry about the quality of the code. Sometimes the code written in not as per our vision and we end up refactoring it. But again, all these things are possible if there is some time at hand. For startup like ours, we are continually iterating and adding code proof points. This makes it difficult to maintain the quality of the code how much ever we want to. I like your idea of documenting, though again, it's time consuming. We do it with helpful comments, but I think it is not enough.

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).

Awesome. This is something I try to follow. I use the same concepts that you have listed here. Conforming to the MVC pattern makes it easier to develop. Since my team is using Parse, we don't have to worry about Data Objects and Web Services, but we do have Controllers, Data Managers and Utility functions in our app.

I checked out your github account for the HN app and it is a beautifully written one. Great work.

Thanks man, I've been refactoring and learning as I go on that one as well. It used to be not-so-nice not too long ago haha.

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.

Thanks for the suggestions. I checked out the book by Michael Feathers and it definitely looks helpful. I have embarrassingly low number of unit tests which I need to take care of and introduce more rigorous testing into our code.

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.

Yeah, google comes to the rescue more often than not, but I also believe that such code that we put in leads to hacks which may bloat up as messy in the grand scheme of design/structure. For me a good code is something that has proper structure, good mechanism for communication between related modules and maybe, free from hacks :)

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.