Yestercode. When writing C, C++ or other text-based languages, I often comment out the code I'm replacing or reworking and write the new stuff just above or below it. The old code is right there for reference.
I've also found it useful to use github in the browser. When writing a feature for the 2nd or 3rd time because the previous wasn't good enough to merge to master, I'll pull up the commits from a previous effort. That readily shows the changes I made last time I tried to do this. Maybe it's odd to be looking at an old diff rather than either version of code but it can be helpful at times.
Someone once told me that Simulink had a visual diff tool, but they were threatened by N.I. for infringing a patent so the feature spontaneously disappeared in one release without notice. (or maybe I have the companies reversed) It might be back by now.
"Boxes and lines" tools are notorious for being quick to start something and taking forever to finish because of a lack of support for maintenance and the related software engineering practices.
Quote:
"The programmers used some pretty interesting strategies to overcome not remembering how the original code worked: they'd excessively use undo/redo to flip back and forth between the current state and the original state of the code (other researchers have found that Java developers do this backtracking behavior too! A lot.), they'd copy and paste the code block prior to modifying it, or they'd screenshot the code to use as a reference!
I also asked 9 other engineers if I could come sit behind them as they were coding. Oddly enough they agreed, and even seemed eager to have someone witness their coding frustrations. It revealed many small reasons why modifying code is tedious (e.g., it is easy to mistakenly swap two inputs and not realize it). They also taught me some more strategies, such as duplicating their entire code project before making a change so that they could compare the runtime behavior of the original version and the changed version. I again saw them screenshotting code and a few of them would make notes on paper prior to making changes."
I am sorry, I don't use LABView, so this might be a noob question, but!: Can't you use a repository and just commit/checkout changes with different instances of LABView opened for each? This way you can compare that at the tip of your fingers multiple situations?
I have used LabVIEW (and other NI tools) in the past, I was even advised by a mentor to learn LabVIEW extensively because it is very lucrative. I didn't, to be honest his strategy was to become indispensable and mine is always to solve problems.
These workarounds cited in the article are almost personal to me, I would see very senior and competent engineers doing things like screenshots and duplicating code and things like that. I even engaged in it a bit, there are other ways in theory but in practice LabVIEW almost always results in incomprehensible spaghetti.
In the end I was part of a change to the department away from NI and proprietary tools and towards python and standardized hardware. It seriously reduced the difficulty in building our tools. LabVIEW is IMO a dumpster fire and I would probably never use it for anything ever again. It is one of those concepts that sounded good in a pitch and then became a huge mess once implemented.
Back at uni our lab just switched from labview to using matlab for automation. Today I’d likely go with Python instead. But the outcome is the same.
LabView and other graphical programming languages suffer under the red-stone condition, where someone will build a hugely complicated jungle of a “program” but feel that it’s simple purely because they build it and remember all the details of it, that is for about a month or so. Then when they come back to it they start from scratch because it’s suddenly as confusing to them as it is to others.
> The first thing I did was go and talk to people using LabVIEW. ... I conducted 50-something interviews with engineers, designers, and managers across many different teams.
Go on...
> Next I brought a handful of LabVIEW programmers into a lab and recorded them as they worked on some open-ended refactoring tasks.
Exactly.
I've never met another developer that observes how their customers (users) use their own stuff. [1]
And it's been 20+ years since I've even heard of an org doing any kind of usability testing. (No, A/B testing is not UX.)
> Prototypes: Yestercode and CodeDeviant
Great and genius. This person is good. I'm sad the world doesn't get to see his other ideas.
> ...a very senior engineer interrupted with "This seems like a solution in search of a problem". Not a great feeling.
No. This "very senior" engineer is a dick. Failures should be celebrated. You tried ideas this impotent chud could not, would not ever even dream of.
Screw him.
Engineering, finding the balance between competing constraints, discovering the art of the possible, is one of the ultimate creative endeavors. We use our cunning and wits to more cleverly explore a domain's huge problem space. "Failure" is just ruling out less fit possible solutions.
Anyway.
This OC (Austin Z. Henley) is a gem. He should ignore the haters.
> How do organizations create an environment and culture that allows such behavior? I've only found a few books on the topic: ...
Innovator's Dilemma
More of a fan of Peter Drucker.
But otherwise, I'm hoping Henley figures out how to facilitate creativity and tells us. I should post a picture of my bookshelf of "innovation" books. Maybe save him some time.
Until then, from habit, I always recommend:
Donald Norman's Design of Everyday Things and followups. He's a humanist and the narratives are relatable.
Diffusion of Innovation, because understanding how and why people are motivated to change, or not, will save you a lot of wasted effort.
Design Rules: The Power of Modularity is the only book I've found that explains what design and architecture is.
--
[1] As a kid, I did a bunch of fun stuff with AutoCAD.
So I shared some stuff with yet another person. Then for some reason I stuck around while they tried to install and then use it. More remarkably, instead of mansplaining, I just sat there and observed. This person struggled. And I could see exactly how and why, without them telling me.
Mind blown.
I had accidentally stumbled onto usability testing and ethnography.
Completely changed my life trajectory. User tested all my future stuff. Learned UI. Bought every book. Met every expert.
Well said. I design board games as a hobby and we go to playtesting events where random strangers try to play your unfinished game. As you said, it quickly becomes clear what works and what doesn't. It exposes you to people who play your game from a different place and with a different goal than you and your insider group. It is quite eye opening. As you said, the key is to stfu and just watch.
Totally. Exercises in humility. Chasing those exhilarating moments when your design just nails it.
"The difference between the almost right word and the right word is really a large matter. ’tis the difference between the lightning bug and the lightning."
> I've never met another developer that observes how their customers (users) use their own stuff. [1]
Is it so rare? I've worked with product managers who did customer visits and shadowed users through entire days and interviewed their managers and their managers' managers to understand their whole job, not just how they used our software. Most programmers don't have firsthand access to users except when they are working on internal tools, and in that case I feel like it is commonplace to walk over and ask to shoulder surf for a while and then ask questions. Generally it's only a problem if the users themselves don't have the freedom to grant permission (like call center employees) or if travel or access to other facilities is involved. (Although you are right that talking to as many users as the author did would required management buy-in for an engineer that needed to push back other work to make time for it.)
The author's case is a special case within a special case: not only were the users internal to his organization, but they were doing software development, which is a job he himself is trained to do! There are reasons why product management is a full-time job, and one of the big ones is that learning the users' business and their job roles is a difficult skill in itself. Usually a user-facing application will have a product manager, and in most cases it won't help if you try to intervene and start doing their job for them.
> Diffusion of Innovation, because understanding how and why people are motivated to change, or not, will save you a lot of wasted effort.
The knowledge in this book is one of a handful that I wish would diffuse worldwide as Common Knowledge.
> and ethnography
Yes! It took me a long time to get here as well but the other routes of a) surveys or b) interviews are mine fields of acquiring bad data.
With those tools I'm hugely biased in favor of ethnography over other methods. I think experienced ethnographers can get more out of interviews than those who aren't. I think it's way too easy to do surveys poorly and fool yourself into thinking you have good data when you don't.*
An interesting experiment would be to have three different groups analyze users/customers using:
a) surveys
b) interviews and
c) ethnography, then compare results.
*I've heard that some places like Stripe have done really good work on the survey front, but I don't know details.
I can't say whether it's solely attributable to the use of usability testing, but I have to say that I find UK govt's online services very smooth to interact with. Head & shoulders above the average.
I've also found it useful to use github in the browser. When writing a feature for the 2nd or 3rd time because the previous wasn't good enough to merge to master, I'll pull up the commits from a previous effort. That readily shows the changes I made last time I tried to do this. Maybe it's odd to be looking at an old diff rather than either version of code but it can be helpful at times.
Someone once told me that Simulink had a visual diff tool, but they were threatened by N.I. for infringing a patent so the feature spontaneously disappeared in one release without notice. (or maybe I have the companies reversed) It might be back by now.