How do you "psychologically" adjust to writing software that you can't "see" or "use"?

Question

I realize that this is a slightly strange and subjective question, but I'd still appreciate everyone's feedback.

My entire life, since I was a kid, everything I programmed had fairly "visible" manifestations. I wrote toy games, publicly accessible database-driven applications later, IDEs and GUI based tools in earlier jobs and later, etc. I always felt that I got something almost "tangible" from the thing I created, because I could interact with it directly, and often I could use it myself.

I'm thinking of going to work in a sector that involves writing mission-critical business code related to accounting. I think I will enjoy the technical challenges that are involved (lots of transactions, quality requirements, etc.). What I'm wondering about, though, is how I am going to feel about code that I don't see "in action" and that I or anyone will never get to see of use. In fact, if all works correctly then I should never see or hear my code again. If it's not correct, I'll know about it because the IRS or the SEC or whoever will come knocking.

Even from a quality standpoint, I'm used to knowing that something works because it not only acts according to spec but "it feels right" when I interact with it. In a business system back-end, I'm not going to have that.

I'm sure that many others here have made this transition. Has this been a problem? How did you adjust?

Edit: By "See" I don't mean that I can't see traces or visualize it's execution. I mean that I don't actually "interact" with it or have a visible aspect to the product, and that it is "UNIX silent" - it works if you never hear from it again. I can obviously test it and everything.

Answer 1

Adjustment = f($$$). If the job pays real well, then you can leave the "visibility" aspect to pet project of yours.

Answer 2

I think if you can't see the software working you're doing something wrong :)

I spend a lot of time writing libraries when I'm not at work. I don't actively see them work because they're mainly functional, structure oriented or thread related. Very few visual components.

But I see them work all the time via

• Unit Tests
• Debugging
• Products which utilize these libraries

The first two should be applicable to any software project. Even though I can't see the end result, I can still see the code running.

I also have a rather fun time visualizing the code running in my head.

Answer 3

Write unit tests. They do what you as a human do, but automatically.

Of course, if you have the ability, use the software you are developing for.

Answer 4

Two suggestions:

1. When everything is working right there is a certain satisfaction that nobody is complaining about problems. The more people who use your code (even if indirectly) the more you can "see" that your program is working -- and making peoples jobs easier.

2. When things are broken, it's still useful to see your program in action. When I've worked on projects like this I've intentionally written programs to help me visualize what's going on precisely to help mitigate the feeling of not having a good handle on the program.

Answer 5

Oh, the glamorous world of in-house programming. It's weird at first, but you get used to it. Unfortunately, the code that you will write won't get to evolve. Once it works, that's the end of it. You won't be able to get any feedback, which I think is an important aspect of programming. As long as you keep doing projects for yourself, you won't go crazy. I always just imagine how people are using the application I created, even if it's something mundane like an Accounting application. Most vertical applications suck because they just get it done quickly and don't really do much testing. Writing a few unit tests and maybe spending an extra few days if you can to smooth out the rough edges that are present in most of these types of applications.

Answer 6

I've done driver development for years, and when I first got into it, a senior dev said something that I never forgot: The teams working on visible stuff get the recognition, promotions, etc. And he wasn't just talking about strategically visible. He meant the GUI, for example.

This holds true because you are not the only one more comfortable with what you can see. Your managers and/or clients also relate better to visibly tangible results.

I think you need to look for ways to make your work appear more tangible to you, and your manager. If it's that nebulous to you, unfortunately the quality of your effort may also be invisible to those around you.

A friend of mine tackled this issue while working on network drivers by generating lots of performance charts for bandwidth, throughput, etc. It made his work more real for everyone, and led to getting a good promotion that year.

Answer 7

Practice behaviour-driven development to get feedback during development.

No matter what the change in behaviour you want to see, writing a unit test for the change up front and then implementing the change will give you the feedback you need: first the test fails, giving immediate feedback that your test is doing something; then (after implementing the change) all the tests pass, giving immediate feedback that your target behaviour is implemented. (Then, you refactor the code you were working on.)

This human need for feedback is more than touchy-feely; it's the very reason why unit tests are such a good tool in moment-to-moment software craft.

Answer 8

Learn to love your trace logs. Seriously, I don't know of an accounting package that doesn't have some form of trace facility used to figure out "what is it doing?" in those cases where something goes wrong. Your visibility is in those thousands of lines of traces that are written and overwritten day after day.

Answer 9

So, you can't test your application? Not at all?

That's terrible. No unit testing, no manual testing, no logs?

Then, I guess you should be very careful with the code, but I don't think that's enough.

Perhaps your company should consider having a separated "beta" server with test data(instead of real data) to test your application? That way, you could actually test your application without changing the real-world data. Far less bugs would go to the production machines this way.

Is this really impossible to achive?

Answer 10

a few thoughts:

• You're not designing the auto-body, you're developing the engine, or other key parts under the hood, that make it work. You can still take pride in the car as a whole as well.

• Without the UI it is often more about pure logic and function, less about marketing or HCI.

• Performance will likely be a key challenge, so there should be some interesting technical puzzles to solve.

I've been transitioning more into middle-tier work as well--it's all about creating the key pieces that make the whole system work. I think it can be satisfying knowing that you created those couple of cogs in Big Ben that the entire clock depends on to function smoothly and robustly.