The first rule of Microsoft Excel: Don’t tell anyone you’re good at it
wsj.com
wsj.com
I even have an Excel spreadsheet that helps me solve Wordle.
Is it Excel-specific though? I've made these kinds of errors with Excel (though not with stakes this high). I've also made them a lot when doing math on paper. And I've also made them in C++, Common Lisp, Matlab, Python, R and JavaScript. Now, with those other tools, it's easier to spot an error in a formula on review - but in Excel, it's easier to spot the intermediary results being off, so it's a wash.
I think the thing to learn is to be more careful, to sanity-check intermediary calculations; these kinds of errors are about being momentarily confused, and will happen regardless of the tool you use.
I am very far from being an Excel guru, very far, but one thing I have found useful is having everything come out to an intermediate result, and calculate against those intermediate results. If you see weird numbers in the middle, then end result is likely wrong, figure out why your intermediate results are messed up. If you want to be fancy, you can even error bound your intermediates if you know your valid ranges.
I did not believe Excel was the right tool for the job. As you might expect, I had high levels of stress until they announced a settlement right before the trial was set to begin. I later realized that I should have done everything elsewhere to confirm that my Excel results were correct.
For a while Excel was messing up basic statistics functions too. Wouldn't be surprised if there was something else not quite right in there.
Either way you’re likely trusting that the underlying code is error free. But most people aren’t checking their python imports. They may or may not be aware of the problems floats can introduce. So on.
I think how confident you feel with excel will depend of what you do with it and how you were taught to use it. Years of consulting basically drilled into me that all my tables should be built as if they were going to be delivered to a client who will need to understand them at some point. If you lack structure however, it quickly devolves into chaos.
For instance, you intuitively start with just a column of numbers, and then when you forget what they are you move the column down one and put a title above it, etc. Working this way I often end up with formulas that are off by one or two cells even though things should be adjusted, and it's hard to audit without mousing over the formulas and just looking.
If I'm trying to write a tool for others to use I'll do something more formal like putting the data on its own sheets and naming them. That helps a bit, but means that all my data is hidden on different sheets and I can't get a holistic view of the problem. And to be consistent in my formulas I'm tempted to use this model even for data that doesn't need it (not an array, for instance). And it still doesn't help for array-bounds type problems.
I think everyone has slightly different workflows and this has no real solid answer. There’s always some trade offs. Just working in excel a lot helps, if you’re working on varying levels of complexity. I do it as a job and often helping others so I have a lot of exposure to different problems and input data types and even the desired outputs.
The intuitive example you mentioned never happens to me for example because of 2 things; 1) I intuitively leave space to add a header, it’s such a common thing to do, my intuition knows to account for it up front 2) if for some reason I ignored #1, I know how to move things without breaking the formula references and when to employ different approaches to that problem. Things like how copy and cut differ, Inserting a row above row 1, etc. One of my little hacks is avoiding referencing a range like A1:C5 and instead will make it A:C if it’s just a basic table of data. Your file may have a ton of references to this table of data once it’s built out and adding a row of data then requires some manual housekeeping which introduces an opportunity for a bug to occur. With my approach, I can add or subtract data or rows and non of the range references need to change. (Someone May point out that you could expand the table range for 6 rows in a way that the other references would expand, it’s true but I don’t design my files for that, because adding a row may have break something else to the right of column C).
A lot of the way i use and setup the data within a spreadsheet is in anticipation or avoidance of future issues. This only comes with experience. Which is kind of my answer to your more complex example. When developing for others, you’re usually trying to hide the data and complexity of things and expose only the useful bits for that end user. It’s not perfect and is very annoying that I have to hide and unhide things constantly to inspect the functionality. But that’s just the way it is. I’ve done some things like written little macros that hide all of the background stuff if a keyword is in the file name (imagine having a dev and prod version of the file, if prod is in the file name when saving all the cleanup and hiding of things happen. That’s what I distribute. The dev version is the same and where I work. When I save that file prod is not in the file name so everything in that macro doesn’t execute.)
"Considering the complexity of Excel spreadsheets and the lack of mastery by many users, we have come to the title of this post: more than 80% of the Excel spreadsheets have errors. Ray Panko, a University of Hawaii professor, discovered that, on average, 88% of the Excel spreadsheets have 1% or more errors in their formulas."
There was some research on Excel's impact on finance with so many errors, but I couldn't find the citation.
https://www.forbes.com/sites/salesforce/2014/09/13/sorry-spr...
Example, put these two formulas in excel:
=(4/3 - 1)*3 - 1
=((4/3 - 1)*3 - 1)
=(4/3 - 1)*3 - 1 = 0
=((4/3 - 1)*3 - 1) = -2.22045E-16
I think the comparable item would be something like VSCode.
In what industry?
Where/how does Excel knowledge factor into this?
Well, we managed a lot of data, mostly (but not only) CSV files. It's very useful to learn a few text manipulation functions in Excel when creating CSV files with sequential and or repetitive content (think TV episodes, etc). Or creating several flavors of CSV for each platform. Yes, a database backend with smart exporting functions might work well, but sometimes fast beats perfect, especially for one-off jobs.
Uploading thousands of videos into YouTube was much quicker with one or two CSV files. By learning some basic Excel, everyone was able to minimize errors and maximize output.
What else could we do with Excel? We could export XML files of our video edits from Premiere/FinalCut Pro, run them through a script into Excel and immediately get a report showing all the editing errors that still needed fixing (we had to edit the videos in a very particular way). This alone saved sooooo much time. Interestingly enough, we were also able to identify individual editors by the mistakes they made (it seems each one had a particular quirk).
I also ran the entire digitizing project in an Excel file, complete with burn charts and velocity calculations.
Over the years, I've received calls from every one of my employees, now on with their lives in other jobs, and one thing they're always grateful for are the Excel lessons.
And once you learn the logic behind building Excel functions and spreadsheets it opens your mind to other uses or more programming skills.
It's much easier to teach someone the power of a few choice Excel functions than to teach them Python from scratch. Plus you can see their eyes light up immediately. Fun times.
I would have never used Excel and macros as the tool to automate the things that I did, but these systems were completely locked down without the ability to install anything or use many online services. I eventually started building more complex tools in Access, and improved or was able to do away with many processes that took many man-hours previously. Without the system constraints I never would've had a practical reason to do such a deep dive on Excel and Access to learn ways of accomplishing things that I usually did through programming.
In the grand scheme of things, those basic "computer applications" skills have been a huge asset to my career and eventually allowed me to break into some more advanced tech related positions with other agencies off of those accomplishments alone. Sure, there were some annoying requests from people to fix some old spreadsheets they had limping around, but in my situation it was completely worth it.
Your story is a common one. Big corporations also tend to get like this, especially banking/insurance.
The Excel to Excel/VBA/Access to developer path is a very common one, and you tend to get devs out of it who have strong domain knowledge in business.
I got good at VBA through this same situation. I had to do some very complex, auditable number crunching on systems that were completely locked down by the parent company of a subsidiary. Excel VBA worked kind of perfectly, because it generated exactly the kind of output that execs could understand, spreadsheets. I developed a style of working where my output looked like it was the tool i.e. I would put formulas in cells rather than hardcoding results in the output, so people could trace the calculations and play with them in the way they were used to.
It certainly wasn't because I loved VBA, I didn't even use Windows at home. I did end up affectionate for Excel, though. All of my personal programming was in functional Erlang at that time, and the idea of having the output of a ton of data processing be a set of spreadsheets that could be further worked with felt a lot like returning a function.
Two different companies I was contracting for asked me to do an Excel tricks presentation for their staff. It made me realize how many office drones are anxiously pretending to know how to use Excel, and that more offices should be giving basic Excel classes to general staff.
Until I automated the whole mess one weekend. Checkpoint emails, files all landed where they needed to be, only I had it via secure channels.
I didn't last.
The resulting code and documentation would then become part of a public library, that both other departments and the private sector could use. Ideally the process would be developed as part of a common SaaS framework to make re-use simpler and to develop a common software stack shared across government.
Just like forums not having repeated conversations because everyone checks if their question has already been answered.
Actual result is a recursive function where everyone promises their boss that the task is getting done, and the n=0 case is the one guy who knows how to do anything and his 10 year backlog of stupid feature requests.
An entirely different conversation for sure, but there are entire industries that exist almost solely to serve Gov't inefficiency.
Later we found out this was actually the case. At first somebody manually tracked stuff in a sheet. Then somebody added scripts for business logic. Another layer of scripts for policy enforcement. Then some other department requested automation, so it got a SOAP API hacked on top of this (COM underneath? I think that's how you access Excel from other apps?).
I wonder how many other Excel sheets are secretly workhorses for big services.
I think it ranks as the most hilarious (from a technical perspective) piece of work I've ever done. To my surprise, the solution was quite robust, and was being used on a daily basis by the CFO and other accountants. Even more surprising is that it carried on working for years, even long after I'd departed the company. Thinking back to that still makes me smile :)
I've seen it manually implemented, but the easiest way IS typically via the COM interfaces.
What the article's really trying to say is "Being good at Excel implies you have a logical mind and the ability to see a way through problems. This is something that others lack".
With any other tool, there would eventually be an onboarding process not just for the thing I built, but also for the tool I built it in. Not with Excel – that will just run, whereever you go.
How to change it, yes. How to get the correct result, probably not.
But well, they will get a result. Many people are satisfied with that.
I'm not sure a receptive t will be able to successfully edit a spread sheet. So easy, to get interdependency between cells to a degree that it is really hard to follow, if you didn't create it yourself.
Or did I just describe Perl? Not sure.
No. That is not Perl. That is C Recursion: https://www.bobhobbs.com/files/kr_lovecraft.html
Python3 is up and coming, and eventually it will get there, but old machines must die before it can reach ubiquity.
Python breaks backwards compatibility with old scripts every six months or so. In practice, this means you have to port scripts every time you switch machines. Virtual environments sometimes address this issue, but they are hit or miss.
In contrast, perl scripts from 1999 often work unchanged on clean 2022 OS installs.
awk, bc, and sh are POSIX base utilities, they are literally preinstalled on every unix derivative.
That doesn't make them linga franca, which is what Scarbutt was asking about.
Hell, ed is a POSIX base utility. Does that make ed's command mode the linga franca of text manipulation? Of course not, the thought is preposterous.
Yes, I would consider awk and sh lingua francae (?) alongside Perl – but in slightly different contexts, namely low-complexity jobs.
I find Perl slightly more suitable once things get a little complicated, mainly because it's footgun:power ratio is better than awk (few footguns, but also very low power) and sh (many footguns, not that powerful).
I have come across plenty of boxen where bc was not installed, so I don't put that in that bucket.
And yes, if I want to describe text changes in a highly portable way, I will use sed (or ed, depending on context) rather than, say, unified diffs. I could accept an argument that unified diffs are also a lingua franca for more complicated changes, but they are harder to write.
I took it to mean "so common that it's available almost anywhere" (which is consistent with the context of the comment).
I've found it extremely useful to rely in tools such as the ones you just listed. Specially because they are often present even in light vms were perl might not.
That it is an advantage does not naturally and unfailingly translate into being a linga Franca.
"vi" being so common (ie. "lingua franca") is what gave it an advantage.
Yeah, it takes a bit of time to become really comfortable, but our accountant was (after the initial take-it-away! phase) really glad i have her introduced to it
Avg←{(+⌿⍵)÷≢⍵}
Also, if you want a non-programmer to quickly be able to learn a language, the more learning resources they have available to them, the more probable it is that they'll be able to pick it up. APL probably don't have as many modern, free and online resources as other languages.> APL probably don't have as many modern, free and online resources as other languages.
Not as many, but that can be a good thing too. Lots of languages have tutorials, libraries and articles that use horrible practices. I write React + TypeScript for work, and it's an especially big problem.
I guess it would, that's not what I said though. Most programming languages use symbols already visible and available on your keyboard without having to do anything extra. APL uses a bunch of symbols you either need to learn a new keyboard combinations to enter, or otherwise extra software you probably haven't used before unless you're a mathematician.
> I'm learning one right now and that's a task much harder than learning some APL glyphs
I agree. Learning new complex glyphs is probably easier than new complex concepts, but what's for sure is harder is learning both at the same time rather than just one.
Using a language like Python or any other mainstream language would at least make the person not have to worry so much about new symbols, but mostly just new concepts.
The "Examples" section on the Wikipedia page for APL also contains a bunch of symbols I would have no idea how to enter on a computer: https://en.wikipedia.org/wiki/APL_(programming_language)#Exa...
It's easy for an English speaking person to consider programming languages in English as the only kind that's usable. To be fair, English dominates in the tech world. But it would be narrow minded to dismiss a programming language solely based on its non-English symbols.
Mathematicians have long been using symbols for efficiency in its expressiveness. Why not programming languages? I'd like to keep an open mind.
Contrast that to APL which has you enter symbols that are nowhere to be found on a keyboard. You need to manually look up how to enter the symbols, or run specific software to have it on-screen, and if you forget, you can't just look at the keyboard, you need to look it up again.
I'm sure it becomes second-nature after a while, just like entering pipe characters or curly braces. But it's definitely harder to get started if there is more to remember than just concepts.
I have not forgotten how long I had to learn English, as it's not my mother language and I had to learn it in school at a certain age. I'm also currently learning a fourth (speaking/writing/"human") language currently, so I'm well aware about that there are other languages out there.
I'm also not arguing against APL as a language as a whole, I'm personally curious about it as well and will probably give it a go as it's currently missing from my repertoire of languages, which is wide already but still missing things. I'm simply arguing against it as a first programming language for people to learn, compared to languages that don't contain symbols you cannot "normally" enter on a traditional keyboard.
Speaking as an old, enthusiastic APL programmer.
Why did you choose APL over something like GnuCOBOL. Ive been pleasantly surprised with how teachable Cobol is to a range of people.
I did chose to show her APL simply because i am somewhat firm in it myself, so it was more simple to teach it someone else.
No R, no Python, VB.NET it was.
Long/complex Excel formulae should usually be broken into smaller chunks, with intermediate results stored in separate cells. For example, if you're calculating two numbers, and then calculating their ratio, it would be better to use three formulae instead of one. That way:
1. Each formula is shorter.
2. Each formula has a single purpose which can be understood.
3. The outputs of the intermediate steps in the calculation are obvious.
This applies also to complex nested IF() statements. Instead of calculating all the conditions inside the IF(), calculate them outside, and then reference the TRUE/FALSE cell values in your IF statement. When you need to debug why you're not getting the result you want, you can easily look at the intermediate calculations all at once, without needing to step through the calculation and check it in the order of calculation.
Especially since pretty much every year we hear another story where some small Excell formula bug cost company millions of dollars. Redesining Excel formula pane should be their number 1 feature in 'todo'.
...unless they still care to add big features at all, and they aren't just in maintenance mode like most of their stuff
There were days I spent several hours clicking "Evaluate Formula" button close to 100 times in a row to debug things like this. The syntax colorization definitely helps, but I would have killed for just the ability to pretty print a formula or set a breakpoint. I'm always shocked it doesn't have features like this that programmers depend on, but I wonder if part of that is because the people that would write something this complex in Excel have never experienced all the tools you get with "real" programming languages.
At home I was getting deeper into Linux and bash/python, and that made me resent Excel even more. I finally moved into the IT department and got really into PowerShell and training myself as a sysadmin, but I would still get requests about that damn spreadsheet for at least a year or two until they finally stopped asking. I used to enjoy problem solving challenges with Excel for a while, but in the end it became a parasitic relationship because of the time needed to fix issues and the complete lack of ownership and knowledge within the department that supposedly owned the form and process.
Critical decisions are made based on Excel formulas like these, (people getting fired, financial decisions, etc.), maintained by people that barely understand programming. Yes, it's nice that it's helped democratize automation and coding for non-technical people, but Excel just wasn't designed for things this complex. When your Excel formulas and macros start to look like this, you need better tools to manage the complexity and trust the maintenance to tech people instead of business people that don't fully grasp the monsters they're creating when they just keep using the only tool they know.
Not sure if the current web/JS based excel still supports those things.
Annoying it's not offered in most versions.
I guess you could have a third sub-cell for style?
When I need to do a complex calculation like that in Excel, I break it up into multiple cells each doing a subset of the calculation, then I have a result cell that brings the results together at the end. that way I can work on manageable formulas and can check the results of each. It’s probably less efficient from a processing and memory standpoint but I rarely work on large data sets and the gains in reliability are well worth it.
I've got some output from something or a table of data I can copy-paste into Excel, quickly do some text-to-columns or string manipulation (tweaking it instantly if I see things don't look right) to get the data into a usable format, then go and build up some formulas, sorts, and plots to answer whatever question I had / get something I can share with others.
Each of those steps is doable with Python + SQLite, but takes more time: I have to write my own data parser (yes, Python's string utils are very good for this, but generally Excel is faster to use, despite using Python for years for my job. I have to then create a schema for the data, and then I have to iterate on my analysis functions, and then finally write my own output / futz around with a graphing library, rerunning whenever I want to tweak something (instead of just changing a cell or chart parameter and seeing it instantly reflected on screen.
There is a crossover point where the complexity of the analysis, amount of data, or otherwise makes Excel less practical, but it absolutely has a place as a super-helpful tool, even for those capable of using more powerful general purpose programming languages.
You might find my sqlite-utils Python library interesting - one of its key features is that it can create the right schema for you automatically to fit the data (as a Python dict or list of dicts) that you pass to it: https://sqlite-utils.datasette.io/en/stable/python-api.html#...
Excel allows non-programmers, of whom there are very many, to visually explore and play with their data. I was already a programmer when I learnt Python; it took many years to learn those skills.
Non-programmers usually do not even want to think about their data in an abstract and general way anyway.
You could likewise say "a huge amount of file operations should be performed with rsync" and just ignore the fact that it's much harder to learn than a drag-and-drop setup.
Of course, this really comes down to using the right tool for the job. Python should be used for automating batch processes, and using Excel manually should be used for data exploration. Jumping into automation before you know exactly what you want is premature, and doing something manually over and over again is wasting time. Us programmers sometimes reach for code writing and automation before we’re actually ready, and waste time writing the wrong code. (I am guilty of this.)
But if those things are not true, if I'm going to be the one to test out an idea and hand something off to my coworker or customer, building in Excel means they're likely to figure it out instead of their eyes glazing over when I explain that they need to install Jupyter, or a text editor, or Visual Studio, or to modify the Lua config file, or invoke something from the command line...they're not going to do any of those things, they're calling me when ~~it breaks~~ their inputs and requirements change.
It's similar in my primary role building industrial manufacturing control systems. Rockwell Automation is a terrible company with asinine licensing fees and outdated technology...but they're the safe choice if you want to transfer system ownership and not get calls about that one machine with the "Linux NUC" for the next 20 years.
Is there a nice library which makes it easy to use SQLite in Python even close to as easy as Excel? Or even as easy as Python lists? Anything which requires me to fill my Python code with SQL strings is (in my opinion) disqualified.
It won't even replace the edge-case uses, n/mind the majority of uses.
I have this theory that a relational database management system is basicly a grown up spreadsheet. and it is, it does great, far better that excel at storing and querying data. And you have better choices for logic, from views to full blown stored procedures(most will probably use an external program instead). all of which keep your logic out of your data.
This should be 5 cells calculating an output uniquely for each possible value of D2. Then picking the appropriate one later on.
If you don’t think networking matters in the real world, then don’t tell anyone you are good at things.
You can say no and be transparent with your time management. People will not get angry about the reality of time being zero sum.
> People will not get angry about the reality of time being zero sum
My personal experience has shown otherwise. If people perceive you as standing between them and doing their job, they're gonna get angry. Of course, people shouldn't equate "not being willing to do their job for them" with "not letting them get their job done." But it happens.
That's why it's all the more important to be transparent with management about these things. Otherwise, your manager may not be able to protect you if someone tries to stir up drama after you refuse to do their job for them.
(All this is to say, I really agree with your conclusion. I just want to point out that people can and do get snippy about the reality of time being zero sum.)
Skill at Excel doesn't always translate well to navigating social and corporate hierarchies well. By showing your Excel skills, you induce demand, often from other team members who are deliberately bad at Excel and who will spend their time on higher-visibility activities and tasks that win them more attention. And you'll be their mule.
It’s a win-win to get leadership involved because then people who are in charge of your pay start using your name more.
Let’s say you are a beginner programmer and good with excel. If you are now doing a lot of excel jobs (and your manager agrees that you should do it) then you progress at excel and less at programming. So your buddies might get promoted to senior programmers while you stay the underpaid excel guy.
You should make sure that you get extra education to catch-up if people ask you to spend time on dead ends.
If you leverage your position as a point person well, you can find a lot of collaboration opportunities and expand your knowledge-base quite efficiently.
It’s one of those warning signs about an organization. When you’re collaborating with fellow engineers, it’s a completely different dynamic.
Demand favors in return. You only turn into the lowly Excel donkey if you let people milk the cow for free.
I have some high level expertise in an obscure system that has a problem once in awhile. The owners know that I will help them, but that someday I will also need a favor in return. It keeps everybody honest.
If they don’t have anything you want, say no.
You _can_ try to get favors back, but becoming a go-to for Excel means you'll spend more time on that skill and less on others, like software development. If you want favors, be a go-to; if you want to get better skills, don't advertise other skills.
Well, that's if someone wants to be the resident Excel guru. Doing so might not fit into one's goals, or might be misaligned with someone's general job responsibilities.
But, more importantly, the implication in the article is that people who are asking for Excel help are looking for handholding; and not everyone wants to handhold as part of their day-to-day job.
For everything else -- and for next level of data manipulations (ie some technical ability) go straight to python (pandas specifically) - or i guess one of those excel + database companies.
It has kind of surprised me that Excel doesn't seem to have copied the multiplayer aspects of Google Sheets (or if it has, it doesn't seem to have taken off). I've worked for several companies that use Google Workspace for most things, but they still have Office subscriptions for most users so they can use Excel in addition to Sheets.
It did and it has.
All documents stored in Microsoft cloud can be edited by multiple people at once including excel spreadsheets and now that most company documents live in Teams, it’s very common to edit them at the same time.
Setting aside that he is a pretty awful human being, his skills at Excel are incredible, and something to behold.
The generalized rule is "If you don't want to do something, don't learn how. If you know how, don't tell anyone."
/s
The article is hilarious and well worth the read.
And they all thought they got an amazing deal.
You gotta be careful though. If you automate too much, that just frees up more time for the Excel folks to make more spreadsheets.
I think it's more "if people figure out you'll do their work for them".
There's a different between (a) helping a colleague with advice/pointers and occasional hands-on help, and (b) independently completing core parts of someone else's job.
This reminds me of this scene from Harold and Kumar go to White Castle, as described in https://conservancy.umn.edu/bitstream/handle/11299/218729/Ch...:
Similarly, in Harold and Kumar, the scene opens with Harold (John Cho)
working at his desk and packing up getting ready to leave. It cuts to a scene
with Harold’s co-workers, two white men, one of whom, Billy, is bogged down with
work and can’t leave the office at five p.m. One suggests giving the work to
someone else, and the scene cuts back to Billy’s giving Harold a stack of papers
and telling him, “I need you to update those models for me.” Harold responds,
suggesting Billy was the one who was supposed to finish the work, but Billy lies
and says he has to take care of other clients and doesn’t have time to get the
work done. After a long pause, Harold calmly agrees and says, “Yeah, no
problem.” As Billy exits the office, his co-worker states, “I’m telling you, those
Asian guys love crunching numbers. You probably just made his weekend.”I feel like only people that I want to know that I'm good at something is prospective employer/recruiter, and whoever will give me promotion at work.
Coolest new one I've seen so far is 6gunz: https://pldb.com/languages/6gunz.html
I love Excel for what it can do. I hate Excel for what people do with it. It's a true jack-of-all-trades application that often gets used when a more purpose-designed application would be a better fit.
My department is constantly hampered by scaling issues because someone used Excel instead of a simple script, database, or a more automation-friendly file type. And most of my department is comprised of software engineers, so there isn't usually a good reason for those things to be consider inaccessible. Judging by the comments so far, it looks like we're not a lone.
Taking many hours to do things that take minutes even if you know some basics. And then when something changes, say, hourly rate, manually redo everything. I have not seen this once or twice but at least 100x from 100 different people who are supposed to know better.
I don’t claim to be good at it but come on. I have too many anecdotes from both big and small companies that abused Excel in every way possible and every way is considered extremely bad practice.
(Off-topic maybe) The other way as well; creating documents with 100s of sheets so complex they can be seen as a small neural net almost and then, because no one really understands it anymore, just connect it up to a webservice via OLE with ASP.NET and there we go. So… many… times…
TiddlyWiki (https://tiddlywiki.com/) is another good example; I can make something great, just send it by mail and know the recipient can open and use it.
Recently did this to solve a particular Brownian bridge. Given a deck of 52 cards, whenever you draw a red, you get $1, and whenever you draw a black, you lose $1. You can stop drawing cards whenever you like. What's the expected value of this game with a full deck? (solution: something like $2.61, don't have the exact number off the top of my head)
You flip the first card. If it's red (50%), you immediately stop and take your winnings (+$1). If it's black (50%), you draw down the entire deck ($26 - $26 = $0). That gives you a guaranteed EV of $0.50/play.
Alternatively, consider the case where you have a deck of 1 red and 1 black.
I tend to become the go-to guy for some system I hate, then I write scripts that people use instead of going to me, and at some point I become the guy who fixes that system for good. Then I apply that experience to fixing other systems, then eventually I start off a big new system in a way that avoids future problems that nobody else can foresee.
I have some people on the business side that are good with Excel, but I usually have to work some magic in Python for them when the row count gets +250k.
I know the row limit is 1M, but when you get beyond 250k your Excel really starts to drag.
The level of knowledge required isn't that prohibitive; nobody using Python in this manner needs to be a computer guru who understands Python C extensions, etc. Pandas is pretty straightforward, and interfaces easily with Numpy for data analysis. It doesn't even have to be Python, R provides similar functionality (but those do seem to the most common and easiest-to-use high-level data analysis languages).
This is such common knowledge that the absence of any mention of it from this WSJ article is itself peculiar, and makes one wonder if this is some coordinated marketing exercise on behalf of Microsoft.
Mysterious constants in formulae, unexpected quick side calculations left over, and poor structure.
The only use I have for Excel these days is as a fancy CSV editor: the heavy lifting is best done in Python.
I feel like HN is often populated by rather skilled and rather disciplined software engineers, and for them almost any language can be a pristine tool and a code base can be beautiful and clean.
For someone who may be analytically capable but not a software developer, I feel that Excel can be the correct tool even if it yields some ugly "code bases". The tool you have at hand is often the most expedient tool to use even if not perhaps the absolute best.
How to you version control Excel sheets? I guess you can technically use git but the diffs will be completely useless.
How do you run unit/integration tests on an excel sheet?
The tests were run every time the sheets were updated so we had a form of test driven development when working with the sheets.
There was a long running project on the go to retire the spreadsheets and replace them with a proper application but that was a multiyear effort.
Excel has a specific use case. That use case is not developing complex software, but quick and simple analysis of data. If you try anyways the result will be bad and unmaintainable.
This could be about any programming language/codebase.
In Excel, you could move those "mysterious constants" into named/described cells in a constants sheet if you wanted. You could also put your formulas in one place and reference them.
This reminds me of the old "Why does Visual Basic suck? Because it attracts BAD programmers" discussions. The reality is that almost no language stops you writing bad code, and older codebases often are worse in terms of maintainability regardless of language choice.
I've seen some absolutely terrifying C code for example.
PS - Excel's CSV support is complete trash. If you open a CSV and just hit "save" it may corrupt data in an unrecoverable way. For example turning long numbers like UPCs, medical codes, or DNA sequences, into scientific notation or dates, dropping leading zeros even if you convert them back.
It's especially easy to access via any .NET language. I've written a few plugins in C#: https://learn.microsoft.com/en-us/previous-versions/office/t...
The problem came when they moved all the documentation to cloud, so you could get hopelessly stuck when you were trying to make something work and didn't have internet access.