Sounds like a good habit to me. First rule in coding is to make it work. Once you’ve done that, clean up your code and make it neat, understandable and simpler if you can.

However – if you are spending a lot of time over designing your solution and wasting a lot of time creating stuff that doesn’t need to exist, that’s possibly a bad habit – like if you were creating a bunch of classes and just going a bit overdesiging mad. But as long as you’re working towards “making it work” then it doesn’t sound like it’s a problem.

My answer may be little off topic, but this method works for me.

Before you even start programming you have to think: what kind of structures I need to solve a problem, and what kind of algorithms.

Often you will find that solution already exist and that you only have to implement it into your project*. Never try to reinvent a wheel – if you need something there is always significant chance someone already done it better.

Once you do that you are only left with gluing those parts (algorithms and structures) together and that is usually simpler than thinking about a problem as a whole.

*That’s why education is so important in IT. The more algorithms and kinds of structures you know the more often, during programming you will catch yourself thinking: “Oh, I know, I have to use this. Oh, and here I need to use that.”

That habit is typical for TDD. First implement it and than refactor. I think every developer does not implement the best way on his first try. As long as you have unit tests to verify that everything still works after refactoring there’s no problem with that.

I find that when I work out on paper what I want to do ahead of time, that I make less unnecessary code. Sometimes I end up with several drafts on paper, so it’s still an iterative process, but the iterations tend to be faster, since you don’t have to get all the way to working code to realize that something you thought was a good idea won’t work after all. (It doesn’t even have to be as detailed as pseudo-code; a simple drawing can be quite helpful. Also, there’s nothing magic about paper, whiteboards work well too.)

Cleaning up code is a good habit, but so is aiming for clean code in the first place. You’ll still need to clean things up even if you plan ahead, but you won’t have quite as much of a mess to start with.

Writing and re-writing code isn’t a problem, nor is writing more code than is absolutely necessary. Every time you write code and throw it away or refactor it you are learning–in fact it’s possibly the best way to learn. Trying to be “Optimal” about your coding type or typing time is really harmful to all involved.

Also, all those “Extra” variables are often a good idea–if they help you understand your code initially then they are best left in there! Don’t fall into the trap of writing minimal code thinking that’s the way to make it readable, Terse code does not equate to readable.

I’m suggesting you don’t get too enthusiastic about “Removing” your code. If it’s absolutely unnecessary, sure, but creating extra functions and more variables tends to be a fairly good thing, if you remove them once you understand the solution, you are only hurting everyone who looks at the code after you (including yourself a few months later).

It IS, however, important to keep your code DRY, in fact that’s what I consider the single most important principle in all of software development, but once your code is DRY, further reducing verbosity from what helped you comprehend and design it is usually harmful.

The best coders and average coders usually have similar code, the difference is how long it takes them to do it. If you take the time to plan ahead and solve the problem before you start coding it will help you become one of the best coders. Obviously you won’t be able to foresee every problem so you will have to make the little things work and that can get pretty messy so what you are doing is called refactoring the code (and this is a good practice). The best thing to do is first solve the algorithm on paper and figure out how you are going to accomplish the task. Then code it and get it to work, then refactor to clean up, make more readable and optimize. Look at how long it is taking you to solve/code/debug and of those three the debugging should take the least time, then coding a little more and solving the problem the most time. Hope that helps out.

Nothing wrong with this habbit in my opinion. The longer you code, the better your coding and problem solving skills will get, thus all of the “extra” code will get less.

I’ve been working as a junior software engineer for about two years now, and still use this sort of approach, with the difference being that as time has gone by, I’ve been more often gunning straight to the trimmed down solution/algorithm.

Test variables is still a common thing for me, but gets used much more efficiently.

So no real worries here, just ensure that you keep it as clean as possible, and use lots of comments and regions.

Just try to mark your extraneous code if possible. Variable checks can be written as assertions for example which add semantical information to your code, I.e. these properties have to be fulfilled etc. Since assertions are usually dropped in “release mode” (depending on language/plattform) lots of assertions do not have to be removed but can function as further debugging help when changing parts of your program.

Similarly for temporary variables that you use for code debugging, name them with a debug_ prefix or something similar, so you can tell their purpose right away.
Programming is an iterative process,therefore what you do is perfectly normal.

One thing to notice: Assertions can be even better than comments in explaining your code. Use them (wisely)!

Verbosity is very common for junior programmer, but you are more advanced that you aware those verbosity and try to remove it.

At first it might sounds like a good habit that you always refactor, but if you need a lot of refactoring after first time it means you should improve your initial coding performance.

Refactoring more often is the key. Don’t wait until your implementation complete before refactoring. If you function is too long, make new function. If your code is repetitive, make a function out of it. Think of refactoring all the time when you code, not just after you finished coding.

Constantly refactoring will help you when you need to review what you have written, and it’s easier to debug. It is common that your code won’t work correctly after the first time, and even yourself in few days later might forgot your own logic if your code look like a mess.

I guess having trouble “foreseeing what is needed” is only natural given your short experience: you are just beginning to learn how to write programs. It takes a lot of trial and error to learn to design and that is the skill needed to avoid extraneous coding. It seems you are on the right path.

Perhaps you already write detailed comments but if not, you could try using comments as a tool of small scale design. Try writing descriptions first. Before writing a single line of code into a method, write a description for it: what it does, what parameters it takes and what it returns, what side effects it has and what kind of exceptions it could throw. You could also outline the implementation using comments before writing code. The same goes for classes or modules: try describing them as a whole before actually diving into details and implementation.

This approach forces you to design something before coding. It could also lead you to thinking about structure first which will be essential further down the road.

The usual sequence is ‘make it correct, then make it elegant, then make it efficient’. The first step may result in as lengthy code as you need, as long as you can keep track of what’s going on.

Gradual refining of code is an ongoing process, and even best programmers are known to say that some of their most productive days were when they removed 1000 lines of code. You should worry when you can’t simplify your large and complex code any more, not the other way around.

The “Do more, then simplify” approach has a major downside: The big and complex methods are very hard to test. And you want a test that documents that your refactored code produces the same results.

So you really need to start thinking about separation of concerns as early as possible, or else you will spend a lot of time wrestling with really difficult unit tests, that could be prevented. You need small pieces of code from the get go. For me, understanding the “Single Responsibility Principle” (SRP) was very important in this context. Also, decency injection plays a very big role here.

It is hard to do this in the beginning ( it still is for me a lot off times), but as you gain experience, you will slowly learn identify patterns in the code, and know how to break those patterns up into simple and testable structures.