My bad LV habits acknowledged, a short list

[MoldySpaghetti]

There's more than what is listed, but I'm going to say the ones that pop off the brain at first thought. This might be useful just in simply being accountable for them ... if they're acknowledged, I might be forced to make more effort to do it the right way.

A list of my bad LabVIEW habits that would behoove me to fix:

1. Maximizing screens

2. Compulsive saving (esp ctrl+shift+s)

3. Not using autotool

4. When encountering a bug that I can't figure out, I sometimes resort to hack & check style. i.e., change something, run it, repeat 5000 times.

5. Not taking the time to build my own toolbox. i.e., cleaning up and generalizing modules that worked well, and putting them into the palette.

Extra notes:

1. This is going to be difficult for me to change. I wish I could spend some time watching some experts develop, because I find myself spending too much time putting the mouse to the scroll bars to go where I want in the VI when not maximizing. The best developers seem to all use non-maximized screens, so I'm thinking there must be something that I'm missing. I develop slower when I'm using non-maximized screens. But I see the rather huge incremental benefit for not maximizing, I'm just not doing something correctly. I'm currently not maximizing in any case where it isn't clearly warranted, but it continues to be painful, and I don't see a light at the end of the tunnel.

2. My first impulse when I do something that I fancy is brilliant is to save everything (Don't lose that thought!!!). I certainly don't need to tell YOU folks how erroneous this is. I'm a fairly compulsive SCC checker-inner as well, largely because of this--I use SCC to revert changes that I didn't like.

3. I've been suffering through using it for the past few weeks, still not completely taken with it. I think this was in a Coen movie ... "I'm a tab man, damnit!"

I'm very close to just switching back to not using autotool at all. I don't feel like I'm losing time by hitting tab and spacebar many times to do what I want. My main problem with the autotool is getting the cursor/tool for selection, sometimes it's only a couple pixels wide, and selection point is in a spot I wasn't expecting.

4. This relates to the fact that sometimes the best thing I can do when I have a real brain-stomper, either a bug or just a difficult algorithm, is to get away from the computer and take a walk, or perhaps just sit down with a scratch pad and pen (is it strange for an engineer to dislike pencils?).

5. These are modules that aren't candidates for openG, but are at least clean and reusable enough that I could save time on new projects.

General:

-Most of these are actually not particular to LV, but I use that far more than any other language.

-I wonder if particular bad habits are more or less common in people who are self-taught in coding vs those who had either more uni training, or simply working with superior SW architects?

-I also realize that there's been reams of books and thoughts on these concepts, but sometimes just writing it out yourself is a better route than reading tech blogs in the pursuit of improving your own habits. And in fact, the latter can be an addictive experience, and can lead to days where you started out with a task in mind and ended up "waking" at 11 am and realizing, jeez, I haven't done anything!

With that recursive irony in mind, an article that I actually dogfooded was Graham's artice on removing distractions, particularly cutting your dev machine off from the internet: http://www.paulgraham.com/distraction.html

~~~~~~~~~~~~

Any bad habits you'd like to acknowledge?

[Black Pearl]

1. Maximizing screens

I once got the tip (I think it was a NI screencast) to develop on a 640x480 monitor to learn discipline on using BD real-estate. Maybe give it a try?

It actually has enough space for two loops with some SubVIs in it (Message handler, Producer/consumer). I can't really recommend it for UI code (property nodes are very large), but almost everything else can be done that small.

In addition, you develop the habit to create a lot of SubVIs, which will help you with task 5.

I would consider task 5 the most important. Get yourself the time to do it (implement a small feature less and have the friday afternoon for reuse design, find some excuses if necessary, accept non-perfect VIs as candidates).

Felix

[Daklu]

1. Maximizing screens

Hold down ctrl-shift to bring up the hand tool and use the mouse to move around the block diagram. Much faster than using scroll bars.

2. Compulsive saving (esp ctrl+shift+s)

Why is this bad?

3. Not using autotool

Meh... that's not a bad habit; it's a personal preference.

4. When encountering a bug that I can't figure out, I sometimes resort to hack & check style. i.e., change something, run it, repeat 5000 times.

Is your hack & check used to figure out what the bug is, or a semi-random guess at fixing the bug without fully understanding it? If the former, no big deal. If the latter... yeah, you might want to rethink that.

5. Not taking the time to build my own toolbox. i.e., cleaning up and generalizing modules that worked well, and putting them into the palette.

I agree with Felix. This is probably the change that will benefit you the most. When I have functionality that is a reuse candidate I do several things before adding it to my reuse library:

1. Create a library for the component that exposes that functionality.

2. Decouple the library it from my app code. (Make sure the library isn't dependent on any app-specific code.)

3. Copy the component source to a couple more projects and use it there as well.

Only after I've used the component in a couple different projects (which almost always results in some changes to better generalize it) will I add it to my reuse library.

Any bad habits you'd like to acknowledge?

-Writing block diagrams that don't fit on one screen

-Routing wires behind structures

[Cat]

Any bad habits you'd like to acknowledge?

Not commenting enough.

Not keeping my personal toolbox up to date. There's probably stuff that's been in there for 15 years that some openG function does much better. Also I have a lot of functions that do essentially the same thing. It needs a good housecleaning.

[PaulG.]

With that recursive irony in mind, an article that I actually dogfooded was Graham's artice on removing distractions, particularly cutting your dev machine off from the internet: http://www.paulgraha...istraction.html

Remove distractions. All of them. I simply cannot "get into a zone" very easily in a cube farm or with a radio on or phones ringing in the din and giggles of a typical office. Music is hit or miss. Sometimes some jazz or something Jeff Beck-ish helps me concentrate. White noise (where I work now - total bliss) or total silence works best for me. As far as cutting off the internet goes, I simply cannot do that. I need THIS place too often.

[hooovahh]

2. Compulsive saving (esp ctrl+shift+s)

I wouldn't call myself a compulsive saver, but I do save after several large changes to the code. But compulsively saving is a bad thing in terms of undo. I recently lost a whole days worth of work by deleting the wrong case in a disabled diagram structure and then saving...needless to say I put in some over time to re-do my work. Luckily it only took a few hours since all the trial and error had been done. If I had compulsively committed then I could have recovered it but this was mostly a prototyping VI (which is why parts were disabled). I hear 2011 now has undo after saving.

The maximize screen bugs me. When I was first using LabVIEW it was on a project where we were reviewing and changing someone elses code. They developed on a low resolution monitor and maximized every screen. So we would open it and have 60% of the screen in white space and would have to unmaximize, then reisize every VI. After this experience I almost never maximize a screen.

[crelf]

1. Maximizing screens

...

1. This is going to be difficult for me to change. I wish I could spend some time watching some experts develop, because I find myself spending too much time putting the mouse to the scroll bars to go where I want in the VI when not maximizing. The best developers seem to all use non-maximized screens, so I'm thinking there must be something that I'm missing. I develop slower when I'm using non-maximized screens. But I see the rather huge incremental benefit for not maximizing, I'm just not doing something correctly. I'm currently not maximizing in any case where it isn't clearly warranted, but it continues to be painful, and I don't see a light at the end of the tunnel.

Unless I'm misunderstanding what you mean, I don't see this as a bad habit at all. I often start with a large (not always maxmized, but usually lfar larger than I think I'll need) BD, write my code, then I arrange things to a more pleasing layout, then I resize the window to suit. That one resize at the end is much better than several resizes in the middle to make the BD larger - that would really get in the way of my (data)flow.

The best developers seem to all use non-maximized screens...

Reference please - I've never heard that.

Remove distractions.

Damn right! Although we have the white noise thing going on here (and it makes a big difference), we have a "quiet room" set up with two mega-workstations with docks, comfy chairs (including a couple for reading) where anyone can go to get away from it all. The rules are simple:

• no cell phones
• no talking
• if the door is closed, don't bother anyone in there unless it's an emergency (eg: the "building is on fire!", not "Can I eat your pizza rolls in the freezer?")

I once avoided my boss for days in that room...

[Black Pearl]

1. Create a library for the component that exposes that functionality.

2. Decouple the library it from my app code. (Make sure the library isn't dependent on any app-specific code.)

3. Copy the component source to a couple more projects and use it there as well.

Only after I've used the component in a couple different projects (which almost always results in some changes to better generalize it) will I add it to my reuse library.

As I'm in the progress to improve and formalize my reuse process, I found that this is the way I'll naturally do it.

I have a 'reuse candidates' folder (under SCC->track changes! and structured into different groups; access is via a Tree.vi instead of the palettes).

During the packaging process (namespacing them with OpenG builder and packaging them with OGPB) I'll select only a subsection of the VIs that have proven in other projects. Only those make it their way on the Team share and my palettes.

Felix

[Aristos Queue]

2. Compulsive saving (esp ctrl+shift+s)

That's unfortunate. Only those of us who work on pre-alpha builds of LV should ever develop the save-continuously reflex. Definitely need to get LV 2011 out stable!

[Grampa_of_Oliva_n_Eden]

That's unfortunate. Only those of us who work on pre-alpha builds of LV should ever develop the save-continuously reflex. Definitely need to get LV 2011 out stable!

I have never thought of the save often thing as being bad. I developed that habit back in DOS 3.1 and it has saved me a lot of potential lost work. Power ouatages are just an excuse to take a break.

Quiet envirnment:

Protective ear-mufs (like those worn wire shooting) combined with ear plugs give me a 6 db reduction in noise. Add an industrial PC chassis fan running and there is no sound distrations. My boss bought a bumper sticker that now hangs in my cube that reads;

"You do not want me to take of these headphones." (AnEnginneringMind.com)

Visitors have learned to approach gradually to avoid me jumping out of my seat (when you are in the zone, you are in the zone).

Ben

[PaulG.]

I have never thought of the save often thing as being bad. I developed that habit back in DOS 3.1 and it has saved me a lot of potential lost work. Power ouatages are just an excuse to take a break.

Quiet envirnment:

Protective ear-mufs (like those worn wire shooting) combined with ear plugs give me a 6 db reduction in noise. Add an industrial PC chassis fan running and there is no sound distrations. My boss bought a bumper sticker that now hangs in my cube that reads;

"You do not want me to take of these headphones." (AnEnginneringMind.com)

Visitors have learned to approach gradually to avoid me jumping out of my seat (when you are in the zone, you are in the zone).

Ben

That would certainly have been a less expensive approach to what I did. One place I worked was so noisy that out of necessity I felt the need/excuse to buy noise cancelling headphones. Good and expensive ones. Music sounded incredible but they didn't work well enough in that environment if I wanted silence.

[Grampa_of_Oliva_n_Eden]

That would certainly have been a less expensive approach to what I did. One place I worked was so noisy that out of necessity I felt the need/excuse to buy noise cancelling headphones. Good and expensive ones. Music sounded incredible but they didn't work well enough in that environment if I wanted silence.

I just remebered that I cheat when it comes to noise. I am completely deaf in one ear (my ear plug consumptions is half of most people) and the other one qualifies me a legally deaf so my method may not work as well for you if not using the industial cab.

Side question!

Isn't the sound of silence after sitting next to a fan all day wonderful?

Ben

[Daklu]

Protective ear-mufs (like those worn wire shooting) combined with ear plugs give me a 6 db reduction in noise.

Only 6 db? Over the ear muffs and in-canal plugs each typically offer ~20 db reduction don't they?

Silence is impossible, so I use background noise to drown out distractions. Usually it's music, but I also have a generator that produces various continuous sounds designed to sooth: Ocean waves, babbling brook, gentle rain shower, Nascar racing, power drills, crying babies... stuff like that.

[crossrulz]

Only 6 db? Over the ear muffs and in-canal plugs each typically offer ~20 db reduction don't they?

That was my first thought. Back in my Radio Shack days, I sold racing headphones (as in NASCAR) that had 60dB of reduction.

Personally, I'm with Paul. I have my iPod and Bose QC2 noise canceling headphones. Sometimes it seems like I can't think without them on.

[Grampa_of_Oliva_n_Eden]

That was my first thought. Back in my Radio Shack days, I sold racing headphones (as in NASCAR) that had 60dB of reduction.

Personally, I'm with Paul. I have my iPod and Bose QC2 noise canceling headphones. Sometimes it seems like I can't think without them on.

Checking the wrapper for the ear plugs shows you are correct!

Ben

[MoldySpaghetti]

Thanks for the replies, all. Rather than replying to every point, I'll recount what I've taken to heart as the biggest panaceas to my mental gout.

Distractions: I greatly enjoyed reading the accounts of this. I don't even like going into the office if I can help it, because I hear other people talking on the phone, or talking about burritos, or playing miniature golf ... all of which are quite okay, but when I'm busting my head to grasp a larger concept, it kills me. I had taken to renting two rooms and using one for an office and developing from there, but that too has other problems.

Hack & Check:

Not commenting: I think a good architecture is worth way more than commenting. Too many times I've seen ridiculous comments saying something like "This saves the data to a file" inside a case that is labeled Save Data, yet has huge coupling problems. I'm not suggesting you do such things, but it's more a nod toward G in general. I've rarely found text comments to be helpful. I am guilty of making modules that "manage data and save them to a database", although I haven't done that for years. Oh you monolithic VI's you....

Maximizing screens: Maybe this isn't such a big deal as I made it. Crelf, I don't have references, I'm more of a gonzo journalist, I just say things and try to support them, and from there it's unsupported. I took what you said to heart, though. I have felt better using maximized screens, and I think I'll stick with them up to the point of saving.

Save often: I have lost way more time from LV crashes than from doing something stupid, at least as long as I've had SCC. Maybe I should soften my stance on this as well.

I guess I was expecting more vehement replies suggesting how idiotic some of my habits were. With this, I'm going to do something else for a bit, and possibly return and study some OOP via LV for awhile.

Daklu, you may be amused to know that I was utterly demoralized a few weeks ago when I saw a LV user group presentation that showed some concepts in LV OOP. He showed (Elijah?) how to solve going from point A to point B around obstacles, what's the shortest path? Sounds simple, right? Well, he showed some classes that were linked-list, graph, etc.

My initial thought: Wow, he wrote all of that code to solve THAT? Really? That set of modules looks awfully well written to be done in a short time frame. Am I really that stupid or lazy that I don't do the same thing??

God, I am totally unworthy.

What I learned later: All of the infrastructure he used was part of an ongoing project to create better LV classes.

-Ben

[Daklu]

Was looking for some old content and ran across this, which I hadn't seen before.

Daklu, you may be amused to know that I was utterly demoralized a few weeks ago when I saw a LV user group presentation that showed some concepts in LV OOP. He showed (Elijah?) how to solve going from point A to point B around obstacles, what's the shortest path? Sounds simple, right? Well, he showed some classes that were linked-list, graph, etc. My initial thought: Wow, he wrote all of that code to solve THAT? Really?

Here's the main problem I've had with explaining the benefits of OOP to people...

Any sort of OOP example is hampered by the fact that it has to be simple enough for users to easily understand it. For simple examples, the inevitible question everybody asks is "Why didn't you just do <insert procedural implementation>? It's way easier to implement." I (or whoever is doing the demonstration) typically start explaining what kinds of changes are easily accomodated by the OOP implementation. Sometimes that is sufficient; usually it is not. Demonstrations are good at showing how to do something using OOP and what can be done with it; they are not good at convincing someone why they should use OOP.

For me, the benefit of OOP is felt through improvments to my entire development process. Testing is easier so I have higher confidence in my code. Change requests are easier to fulfill without risking introducing undiscovered bugs. APIs between the various internal components are better defined, making the whole process easier. Overall I experience far less frustration during development using OOP than I do using procedural programming. Those improvements are tangible to me, but they're not something I can demonstrate to the listener.

In a nutshell, the real reason I use OO instead of procedural programming is that I can create higher quality code faster. Generally speaking, I can get 80% of the requirements done faster if I program procedurally. Those "positive functional requirements" are the requirements that define the application's reason for existence. It's that last 20%, the "by the way" requirements, that takes much longer to implement and test correctly. These are the things people usually don't think to specify when defining the requirements--specific error handling or UI behaviors, a "pause" button, "unattended" mode, etc., but ask for when they start working with the app. Often implementing that last 20% requires either, a) rewriting significant portions of the application, or b) allowing the various components to become more tightly coupled than they should. Neither option is desireable. Option a is essentially throwing away all the time and money spent working on the code that's being tossed out. Management tends to frown on that. Option b is incurring code debt, which management usually ignores until the app's growing fragility causes the manufacturing line to be shut down while the software team scrambles to untangle the mess of interconnected hacks and quick fixes.

[Edit: Having typed all this up I realized my comments aren't relevant to the point I think you were making. (Reusable class libraries?) Oh well... I'll let them stand.]