[CoreFracture]

Hello everyone!

I'm new here and figured this was the perfect place to ask for some advice. I've been programming as a hobby for years and as a side thing at work for a couple. Over the past few months as I begin to work closer with the actual programmers at my company, I'm aiming to make my code as professional as possible. However, as I work on this goal I'm finding more and more that I'm spending all my time thinking about the code layout and structure rather than writing it. It seems like I'm spending hours a night thinking about how I'll make the code structure in the most robust and maintenance free way I can think of. But at the end I find I've wasted all my time thinking about that and not doing anything and it just becomes a repeating pattern.

So the general question would be how do you avoid falling into this pattern?

Thanks!
-CF

[tlhIn`toq]

Quote

I'm finding more and more that I'm spending all my time thinking about the code layout and structure rather than writing it.

Good for you! 99% of the people I see here spend 3 minutes thinking and 100 hours typing. Then they come here asking

Rookie said:

I've coded myself into a corner and I can't figure out how to fix it. What do I do?

Certainly there is a point where if you never code anything then all the planning goes to waste. But otherwise the more planning you do the less headaches you'll have when you build.

But you really do have to accept that more is learned through failure than success. Build your projects. Learn from your mistakes.

Remember that if you really embrace the OOP concepts that it is a lot easier to upgrade. Sure its a bit more work up front but it should allow you to get coding and upgrade later. For example, don't pass around List<string>... Pass an object that contains a List<string> even if the class object is overkill. Because 6 months later when you realize you need a method as part of that parameter being passed you can just add it to the class instead of having to replace 60 references to the List<string>. There have been numerous times I've been saved by building my methods to always accepts collections of objects instead of just 1 even though the original spec only called for one. Months later my boss says "We have this customer with an atypical need that will call for handling several widgets at a time..." So for months those methods were looping through collections of 1. No harm, no foul. All of a sudden they can be used unchanged for this odd need.

But again, what ever you do plan, plan some more, plan on a whiteboard, walk through the workflow yet again.... But then actually build the project. Think about it this way... If the people that designed the USB3.0 spec never actually built USB1 they wouldn't have learned enough to build USB2.0 and now USB3.0. If they had spent ALL of their time planning, and redesigning, and replanning, someone else would have built the bus the rest of the world used.

[jon.kiparsky]

Mapping it out is great - as our Klingon buddy says, the opposite error causes a lot more pain.

No disagreement with any of his advice: map it, and be sure you start building. Some added tips
- give yourself a time limit for planning. What that time limit will be depends on the scope of the project, but suppose you give yourself a week - at the end of the week, you know you have to either stop or else revise your calendar.
- work to a calendar from day one. If you have a firm end date for the project as a whole, you know that spending more time on this bit here means dropping something off the end. If you have a calendar - even a rough and flexible one - then you know what's getting pushed off for each delay. This tends to focus the attention.
- work top-down and breadth-first. Don't get down into the fine-grain details of any part of the design until you know the overall structures are in good shape.
- don't just design the software, design the development path. Decide early on what release 1.0 looks like - not so much in terms of styling and color schemes, but in terms of feature set. Lock in that feature list and use it to plot a path to 1.0, with milestone releases placed close together (a week is reasonable, two weeks is also reasonable - not more) and features assigned to each release. This keeps features small and prevents procrastination. Doing this in the design phase is a good reality check. Not only do you have to ask "who will bell the cat?", but also "when will we bell the cat, and what needs to happen before that, and when will all of that happen?"

These are some of the rules that I try to stick to. They're all really about creating accountability for yourself and your team, so it's best to state them explicitly upfront and ask your team to keep you honest on sticking to them.

This post has been edited by jon.kiparsky: 26 January 2012 - 02:43 PM

[CoreFracture]

Thank you for the replies and advice! Its great to be in a helpful place for once

[wordswords]

It's worth saying that you can never code a perfect program. It is not obtainable. There will always be areas where you want to improve, or would have written differently, and so on. Professional development is always a compromise between quality and speed. As long as you are delivering fixes in a reasonable amount of time which aren't junk, then you will look good to your boss, and probably get to do more programming, which will in turn improve your ability.

This post has been edited by wordswords: 27 January 2012 - 04:37 PM