A question for any code jockeys

[Ghoulish Delight]

So I've taken it upon myself to improve my code development skill. I've been through countless introductory programming courses, and some algorithm design courses, but I've never sat down to do anything practical with any of that knowledge, so every time it just slips away and I have to start over.

I'm starting easy on myself, using Python to automate my work (which consists in large part of telnetting into devices, turning ports on and off, and checking log files for errors. Or other similar and related operations). In doing so I can make my job easier, improve my personal skill set, and make myself more valuable inside and outside my company (my company is beginning to give automation priority and I hope this will position me to be a contributor to that as it gains steam).

Anyway, enough backstory. My question is one that I'm guessing is about preference, style and individual ability, but I'm curious to get the opinions from people who do this for a living. Regarding code robustness, do you build it in as you go, or do you focus on functionality first, robustness later?

In my limited experience I've generally been focused on functionality. I've rarely written anything with the intention of sharing it with anyone, so I almost always have total control over the environment and inputs, so I can save a lot of time by hard-coding things and assuming no errors in dynamic input.

But when I then want to go back and expand on something that worked well, or clean it up to be sharable with someone else, I find I practically have to start from scratch because all the error handling and dynamic configuration type stuff requires major changes.

Now that I'm trying to create something more permanent, I've been building robustness in from the get-go. It's going pretty well, and I'm learning a lot in the process. But I'm sacrificing speed big time. I've been working for a week and, while I can gather input dynamically and incorrectly-formatted input is handled seamlessly...my code doesn't DO anything yet. Which, considering I'm starting by porting a handful of already functioning windows batch scripts to Python, seems like pretty poor rate of progress. When I started it felt like doing some error handling and input formatting up front would be a huge time saver in that it should make everything modular. Centralize all the data collection and error handling, plug the functionality in. But every time I feel like I've gotten to that point, something else pops up that requires me to rethink and rearchitect the stuff that came before.

So, to the pros, what do you prefer? Quick and dirty, clean it up later? Or slow and steady, build a solid foundation and worry about "making things work" only once the basics are in place?

[scaeagles]

If you are looking for something that is permanent, you MUST start with a good base. Quick and dirty is not the way to go, as will will undoubtedly pay for it later.

I speak from the standpoint of having done quick and dirty and had to redo it later or try to work with it when modifications and adaptations are difficult because of what was originally done. It always takes more time in the long run to modify quick and dirty than it does to do it right.

I am in an environment now where speed was the key to the success of the business - getting functionalyity up for users because the few customers the business had were its life blood and it was necessary. However, a deade later after being acquired and converting to new technologies, it has become nearly impossible to adapt older code into working in conjunction with these newer techs and we are literally rewriting almost every piece of code in our system.

Assuming you are not the only one who will ever need to modify the stuff you are doing, take that in to account as you code in terms of documenting in your code. Well worth the time.

ETA: AVOID HARD CODING AT ALL COSTS!!!!!!!!!!!!!!!!!!!!!!! If you need to hard code, develop some form of table that can be accessed so that any necessary changes are data changes rahter than code changes. An example might be a connection string. Rather than hard code in a way that might need to be recoded should server info change, have a system level variable that can be modified in the database.

[Ghoulish Delight]

You know, the question sounded a lot less "duh" when I formulated it.

The thing is, it's unlikely that anyone but me will be using this code I'm writing right now. So I've already built in a level of robustness and modularity that's beyond necessary. But it would be nice if it served as a good demonstration of what I'm capable of, so I'm just trying to find that balance of demonstrating that I comprehend the concepts of robustness and good programming practice, while also providing functionality.

[scaeagles]

Didn't mean to insult intelligence.

[keith - SuPeR K!]

If you build this strong foundation, won't it be reusable for other projects? After years of building websites from scratch I finally got a to a point a few years ago where I asked myself "Why am I starting from scratch every time?" Since then I've built up an entire content management system that runs most all of the projects I build. While I still have to go back and recode some parts of the various functions on occasion, the function names and output formats are the same so I can just upload the new version to my older sties and they automatically get the new bits and better functionality without really breaking anything in the process. While I've spent years working on my CMS project, it's still not 1.0, but it works just fine and in the long run it has saved me a ton of work! Plus, I can eventually package and resell what I've done once I feel it is ready.

Take your time devising the base. I've rewritten mine several times when I found better ways to do things, but it's been worth it to me to have that stable base to work off of.

[Ghoulish Delight]

Originally Posted by scaeagles

Didn't mean to insult intelligence.

None taken. Just rereading my post, and your response, and realizing that really the answer was obvious (I practically answered it myself in my OP by pointing out how useless all my old "get it done" code is).

Originally Posted by keith - SuPeR K!

If you build this strong foundation, won't it be reusable for other projects?

Oh, no doubt. I'm definitely designing this to be a "test script platform" rather than a collection of test scripts. But there's only so long I can write code to parse config files and handle exceptions before I want to see some freaking lights blink!

I think I'm approaching the point where I can do some #DEFINEs to temporarily shore up some holes in a way that lets me go back later and improve. Just trying to find where that line is.

[Capt Jack]

Ive been doing the code toad bit for something close to 30 years.
so, some "old skool" thinking:

robust vs flexible vs quick vs (wtf ever). there quite often arent really any hard and fast rules for getting from A to B. in some shops, they do enforce coding standards and can be quite nazi-esque about it at times....others, not so much. seems any one thing can be done 1000 different ways, and everyone you meet in the industry seems to have a different take on it.

the shops Ive worked in allow quite a bit of flexibility and "personality" to be included in code. many times because they will be coming to YOU when something isnt right. robustness, longevity and durability can be built in from the start and often should be designed in before you ever code line 1. do it once, do it right.

thats all fine and good...right up to the point they (the user) change their minds. that can and does muck everything really fast and can flush your complex logical flow right down the drain.

code backwards. start at what you (or they) want and design a path backwards to your starting point. oft times that starting point isnt where you thought it was gonna be.

hardcoding is bad. avoid it if at all possible, but understand, that in some cases, it can be your best friend and reduce making something overly complex. if its built just for your company and needs a company ID or name that isnt going to change any time soon. it "can" be safe to use, vs creating some mish mash of code to extract it from a special table stashed in X database somewhere as 'reference' that some twit will mess up at the worst possible time.

as my "mentor" taught me: code with the thought of "do you want to debug that thing at 2:30am when it fails?" in mind.

then try to be straightforward and to the point. fancy schmancy logic can be a lot of fun to code and get running and give you a real sense of accomplishment...and then turn around and be a complete biotch to debug. even worse when its not you that has to debug it or conversely, have to debug something some old time assembler programmer built. they will curse you and your kin for an eternity (or you theirs) for making something too complicated to discover issues with, and ultimately correct.

so, no "real" advice...but just some survival tips for going forward.

K.I.S.S. rules the day.

rotsa ruck

[Ghoulish Delight]

I knew I could count on you Capt.

Meanwhile, in the last 20 minutes I had an epiphany that should allow me to get an honest-to-goodness functional test script up and running in about 10 minutes tomorrow morning with no further structural changes to the underlying platform necessary. A multithreaded test script no less! It might necessitate some tweaks in the future if I alter said platform, but it should be mostly cosmetic, and localized to meta-data type stuff, the meat of the coding should remain fairly agnostic to the structure around it.

And now that I think about it, that kinda helps solidify where I want to go and what I was pondering when I formulated this thread. I think it will help me a lot to separate the development process into 2 different "threads". Creating the test harness that the scripts plug into vs. designing the heart of the scripts. The latter can remain quick-and-dirty, whatever it takes to flesh out the logical flow of the scripts. Then, if I do my job right on the former, it's just a matter of porting the quick-and-dirty version to follow the template.

I think that's where my hesitance to "build the foundation" was coming form. If I'm thinking too much about error handling and portability and readability and whatever while trying to just figure out the best way to run a test and analyze the results, I get bogged down and never finish. I think centralizing all that will save me a lot of mental bandwidth.

[Gemini Cricket]

Are code jockeys short like horse jockeys?

[scaeagles]

At 6'1, I am the 2nd shortest person in my 8 person development department. Shortest guy is 6'0. I would guess that means no.