Does writing Good code take time or I am just slow?

7 points by geekodour ↗ HN
I am a beginner, I've been programming for last one and a half year I can pretty much make my code what I want it to. I have not worked with any other programmer yet, So If I have to I do the frontend designing to the processing code to the server maintenance. So I was writing the processing code a while ago, It will be around 700-800lines long splitted files(with comments). It takes me quite a white (hours) thinking about how I will solve the problem, there are quick solution that I can run into but I think for a better one ( that too what my institution tell me ) I have not done any algorithm analysis or anything. I will start on that soon.

But does writing good code take time and thinking or I am just slow?

6 comments

[ 0.20 ms ] story [ 23.6 ms ] thread
Yes and yes
Good code takes time but if you want to make a real product your going to have to make compromises.
It is hard to tell based on what you wrote if you are slow or not. But not working with others can also make it hard to tell and many times will the lack of people to bounce ideas off of makes you slower, especially when you are newer.

In general, writing solid, production level code takes time. I have had developers throw up code that mostly works and can't understand why when I go to make it production ready it can take 10x longer to do it correctly. But even if you have lots of experience you will underestimate some tasks and they take you 3-4x longer then you expected.

Overall, the more time you spend in design the less time you are writing code. And the more tests you write (in general) the less you'll revisit code. Also, the smaller each chunk of work is, the better. I try to use the rule a function/method has to fit on a laptop screen view. Doing this means you keep each function/method doing only one thing and believe it or not will speed up your development not slow you down. There are those exceptions when the function is uber simple but maybe has lots of if/else for state transitions or something similar where with whitespace and comments etc the method is 2-3 pages.

I find it can be relatively quick to write a prototype that does 90% of what you need with a few critical bugs but to get it finished, mostly bug free and with high quality concise code can take a lot of time. It can take a while to understand the problem fully and understand the common patterns in the code that lets you find the right abstraction that will simplify it all.
Over time you will learn ways to write code much faster. It's the thinking part that you can't speed up too much. This will tempt you to write lots of code before thinking, because it'll make you feel like you're more productive. The downside of the "code before thinking" approach is that you'll spend a lot of time debugging due to a poorly thought out program, and everyone knows that debugging is no fun.

The best programmers I've worked with design their programs to minimize potential bugs, and so they spend more time designing (of course) which is fun, and implementing a good design, which is also fun. They do end up with some bugs of course, but not nearly as many as with a poorly designed program.

I think you have no trouble with typing, because you care too much for your code quality, it makes you slow. However, you are doing good thing for other people - who will work on your project and for yourself.