In Defense of Regressions Toward Data Entry

Programming, whether you call it ‘dev’ work or ‘software engineering’ almost always includes some amount of work that resembles Data Entry roles. In my past I’ve experienced more and less, but it really makes me think. In this post I’d like to defend what I think are reasonable data entry tasks and draw criticisms against needless ones that represent outstanding requirements.

Working for my former employer, it wasn’t exactly data entry that drove me to quit. It was a variant of SQL data entry but in the form of lots of template .sql files that I would modify to make database changes necessary because of failures in the software or lack of coverage for certain business needs.

When I started, there was by far and away a higher proportion of writing code for new features and fixes than modifying database rows. As I was acquainted with parts of the system I was finally put on a rotation working an internal helpdesk, and later the time spent on that helpdesk was made to be a more frequent focus of my role. It was a slow burn that took me from excited to be a part of the cubicle city to a tenant in the cubicle jail. Of course there was a bigger problem here, but I didn’t have anywhere near the clout to imagine helping.

The bigger problem at this employer was that nobody took direct responsibility for their code, or rather they couldn’t. The plurality of a 1k+ org was directing their internal software failures to a handful of people on my half-dozen person team out of a 100+ software department. Even if the person who wrote a bug wanted to know about it, it would take the person on this small triage team knowing or researching to find it might be their bug to direct it to the correct person. Instead, most of the issues were handled before they got back to engineers to spot a necessary fix. No feedback cycle at all, and certainly a good way to stack a feeble system before knowing what bugs already exist in your foundation.

Since then I’ve moved on and I’m much happier just overall. There’s still an ‘on-call’ rotation for system monitoring channels and I’m part of it but most of the time I’m actually working on software. I still see some data entry work, but it’s there because systems are still being built out. If I’m in a data entry role, for example, it’s likely only because it made sense for a process to start out as a manually triggered app. The amount of work I do in data entry continuously decreases and processes run more smoothly as we account for edge cases and bugs.

These two contexts are just about at extremes: the first, more soul-draining job being a corporate role with very wrote-memorization type of tasks, working almost against systems to fix data while responsibility was missing. The latter, more rewarding role being at a much smaller startup that’s still developing new products and taking them to market. I think they highlight a right and wrong way to approach software, though I’m no expert on business. Aside from profitability, I can report that the people working at both places were kind, if not a little more motivated at my newer role. My thesis is that the startup I work for notices business need, engineers bottom-up solutions without too much “future proof” too-clever-by-half code. The larger enterprise saw software as some form of integration and data correction problem as it hadn’t had time to develop in-house tools or meaningfully get away from aging payment models and code that had to run. I think the markets around these businesses generate very different incentives and much of the same decisions may be made by the other workforce facing the same, but the difference in culture was still a strong shock, having only worked in a tiny startup with ‘bro’ culture and freelance before joining the larger stable workforce.

Whatever you’re doing, if you’re doing it a first time but you know it will very well come up again, that’s the target of automation. The third time a person does something a computer could conceivably do, it’s worth putting it on a wish-list so that it’s visited in planning. More than anything, future plans at my new company give me infinity more hope for my future. Especially when juxtaposed with my first “big boy” company’s lateral team freeze and never-ending increases in helpdesk work.

Hope is real, and it really affects your life. I’ve had none and I’ve had a lot. I think having a lot of hope is great and having none is literally all you can think about, and that’s torture. Employees have to pay bills, but I’d be dumbfounded if they aren’t more productive when they think their work is sustainable and always getting better.

I hope you’re striking a balance in the data entry work you have to do, and thanks for reading!