Hacker News new | past | comments | ask | show | jobs | submit login

I've been stuck in an Excel only situation and it was extremely unproductive, and I knew with certainty that going past a very low complexity threshold would make my code 'write only', subject to bitrot when it would eventually be thrown away to be replaced with yet another spreadsheet.

Although spreadsheets are not great computational models for many tasks, they can be made to get the job done. The problem is easy introduction of errors and maintenance pain -- enhanced by the fact that 'anyone can do it's means no one owns solving the problem and staffing it someone with coding skills. It's like leaving basic toolboxes around the office and saying 'no we don't use electricians/plumbers/carpenters, too much overhead, just DIY'.

So yes, consultants often get the job done with Excel+VBA, a few Access DBs etc. Sometimes it is self-maintainable. The fact that Excel can get the job done (and comes with inbuilt software updates and budget) makes it easy for IT. But it is doing business critical work, using it is only papering over capability gaps.




I think such situations are really something that needs to be felt out -- I'm not really a programmer, but I know how to code, and in my line of work, it's a benefit for sure. We don't develop projects for external or internal clients, but there are times when being able to punch things out in lowest-common-denominator programs/languages is really handy, and the idea of long-term maintenance isn't really a factor in such decisions.

It's all about the problem-set you're working with; the problems I come across are either:

1. Time-consuming but rare tasks that require a pretty intimate understanding our product's code; one-off solutions in various lowest-common-denominator languages are fine, even if they need to be updated eventually because typically the problem is not so common.

2. Simple, static, non-changing tasks that can have one well developed script from the beginning and the only "maintenance" is QOL maintenance.

When these are the problem sets you're working with, the burden of knowledge typically is not so heavy to transfer. They aren't urgent "our company/workflow dies if this sheet/script fails", so there is time for someone to explore and learn.

I get a lot of interns that have never touched code in their life that cut their teeth on little projects like this, and in the event that we don't have someone interested in such things, even then someone still picks it up, just not on an ideal timeline.

I do get what you're saying on the 'anyone can do it' problem basically just becoming a warped version of a prisoner's dilemma where the end result is no one does anything, but at the same time taking control and mastering such workflows and lowest common denominator languages helps inspire and grow people. Powershell is great for this (and I really don't like powershell), and Excel does similar things with the mind especially once you hit the limits of what is built into the UI and start looking at scripting as a solution.

Excel, Powershell, and other such things are burdensome and have many rough edges to cut on; but they are extremely empowering for basically every user, and often a gateway to showing some people a skillset they never realized they had.


Yes that's a fair statement, but I think you can get a lot further with 3 day python course and a locally hosted Jupyter instance (and from an endpoint security perspective, no need to worry about VBA or PowerShell on the clients either).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: