Why do every explanation has to involve some arbitrary logic? I'm confused enough seeing "credit" and "debit", which is a standard accounting doublespeak, and this "Yin", "Yang" makes even less sense.
It boils down to only one principle: "Every transaction must balance". This is similar to the base natural law of energy conservation. There's no free money. Money going to one account has to come from somewhere.
The rest is convention, what we call income/revenue, expense, liability and equity, and how to structure our accounts and reports. It's all nicely explained in http://ledger-cli.org/3.0/doc/ledger3.html
Give ledger-cli a try. It has superb manual, and after reading it I stopped being cofused by bookkeeping terminology used elsewhere.
People who are new to book-keeping typically already have a mental model of it from bank statements. The salary is "credited", and withdrawals are debits. This notion muddles things up.
"Every transaction must balance" is a succinct explanation, but it is unfortunately even one more level abstract for someone not exposed to the very idea of book-keeping. The hope is that showing a few entries without being muddled in what is debit and what is credit territory, and how they relate to each other will trigger the aha moment a little sooner.
I guess the bank account thing would be confusing initially, but it really just needs to be explicitly stated upfront that the bank account is drawn up from the perspective of the bank, and your accounts are literally the inverse of the bank's accounts. The muddling up of debit and credit because of bank statements should vanish quickly after that.
While you're right about balance being fundamental, debit representing what you have -vs- credit representing what you owe is critical in understanding viewpoint, designing the balance sheet, and communicating with accounting professionals.
Why is this voted down? The author here isn't being flippant nor religious nor obtuse. Yin/Yang represent the idea that head/tail, good/bad, pretty/ugly are dependent on your perspective. When working with complex information, realizing that you can approach the problem from different perspecives is critical to communication.
Look at this poster's history. He's got a track record of thoughtful contributions -- this post is no deviation. Just because you don't understand what he's saying doesn't make his comment incorrect or irrelevant.
Thanks Clark for this comment. Downvotes without explanation doesn't help the poster understand what went wrong and fix it in the future. But I suspect it was the Yin/Yang analogy and lack of an introduction that flipped people.
The analogy is used to show how both debit and credit have a dual and interconnected relationship than the more simplistic notion of being opposites.
If anyone is interested in this way of looking at bookkeeping, here is a lengthier explanation with examples: https://github.com/jasim/bookkeeping
I think that the major challenge in understanding debits and credits is that different accounts have different 'signs' that may seem counter-intuitive.
For example, if you earn money (get revenue) this is something that you would typically consider 'positive', however revenue is a credit account and so the earning of revenue is actually a credit.
A simple trick is to recognize that balance sheet accounts have signs that align with our intuitive understanding of positive and negative, whereas income statement accounts are flipped. To grok why that is gets a little more tricky and the linked article seems to give a great basis for understanding that.
Source: I'm a Canadian CPA, CA (and CBV) and soon-to-be software engineer. I think this helps understand both perspectives.
> A simple trick is to recognize that balance sheet accounts have signs that align with our intuitive understanding of positive and negative, whereas income statement accounts are flipped. To grok why that is gets a little more tricky
For me, what made this less tricky, was thinking in terms of flows and their accumulation. A debit entry is a flow of value into an account, a credit entry is a flow of value out of an account (a debit or credit balance is simply an accumulation of those flows.)
We also believe that classifying expenses as debit-normal on the income statements, thereby obscuring their contra-income status is part of the puzzle.
As a former bookkeeper, I should mention that this is technically bookkeeping, not accounting, which vaguely corresponds to the difference between computation and programming.
That said, this is very dangerous knowledge; once bookkeeping makes sense like this you will constantly have to resist the urge to yell at people who claim "expenditure X really shouldn't count because it has benefit Y", which is a disturbingly common belief among otherwise smart people.
I wouldn't try to separate bookkeeping from accounting too much. As a cpa, the lines are blurred too often because we're usually making decisions and adjustments along the way.
But, a little information can definitely be dangerous. It can be a huge time sink to "restate" the books to suit someone's vision and at worst it allows people to misrepresent the information.
>I wouldn't try to separate bookkeeping from accounting too much.
I think of them as distinct and separate concepts:
bookkeeping: the recordkeeping of transactions. The "data entry". You can have lower wage data entry clerks tearing open envelopes to type in data from vendors' invoices and recording deposits of checks from customers. At this layer, the data needs to be recorded correctly.
accounting: literally the management of "accounts". This is a position of education (CPAs). Their value-added thinking happens above the layer of bookkeeping. They use professional judgement to set up a "chart of accounts" ... what kind of buckets to keep track of various money, how many buckets, etc. They are in charge of "closing the books" each month and preparing financial reports.
Yes, sometimes the activities blend into each other. Some bookkeepers do higher level "accounting" activities and some Certified Public Accountants also do grunt work of "bookkeeping" but they're still separate cognitive activities.
Lastly, there's finance. The finance layer sits above accounting and bookkeeping. Finance management (CFO, treasurer, etc) focuses on strategy of money. Should the company lease or buy the building, the tax implications of foreign earnings, stock buybacks, etc. The accountants & bookkeepers can report exactly how much money is sitting in the bank but they are not the ones who decide what the best strategy is for it.
It's the small businesses where "bookkeeping" and "accounting" are synonymous (e.g. using Intuit QuickBooks). In those mom & pop shops, the "finance" strategy is handled by the owner(s) of the company.
From your description, it sounds like bookkeeper:accountant as DB-user:DB-admin - the accountant/admin defines the schema, and the bookkeeper/user only gets to work at the data level, with no metadata level decisions. Is this analogy sound?
I believe this is a good analysis if you see the DB administrator in the role of scheme and report design, interpreting reports, and using those reports to plan for the future, and the DB user as inserting new rows (never updating!) and doing simple queries on the data.
I've wondered the difference between a good bookkeeper and a CPA. After looking at your comment, I finally looked up the requirements to become a CPA. I won't list them; they are easily found online.
I have wondered the difference, because I had two friends who had vastly different incomes, but were doing essentially the same work.
My first friend(former girlfriend in college) became a CPA, and was working for a small VC.(when I knew her I don't think they were calling themselfs venture capitalists? They were just small cap investment firms--basically a rich guy who invested in small business.) Well, since she was a CPA she had no problems in obtains jobs, and salary was not an issue.
I guess she was a good accountant?
My other friend who dropped out of school, and didn't get his bachelor's degree went into bookkeeping. He took a tremendous amount of business and accounting courses at various community colleges. He wanted to get his CPA, but didn't have the auditing experience(not required anymore in CA), and didn't have a bachelors degree. He did some amazing things for just a bookkeeper. He was highly instrumental in making the owner of a small local bike manufacturer a multimillionaire. He was always working, but never got close to the salry of the CPA. I recall him saying he coukd pass all four sections of the CPA exam, but couldn't get his license because he lacked the education/auditing requirement.
I have thought about the two over the years; and without a doubt If I needed an accountant, I would hire my friend without the CPA license. Why, because I know what he did professionally. I still think about that deal he put together. I know we need a CPA licensing system, but don't discount the bookkeeper with the spectacular work history?
My point is get that CPA if you can afford it? I'm pretty sure the bachelor's degree can be in any major. You need certain amount of accounting courses, and a one year of experience working under any CPA, at any company.
(What I find troubling in CA is under Brown--it appears Lobbiests got their mits on Gov. brown and made it harder to gain entrance into certain professions. I'm not sure if easier, or harder to become a licensed CPA before Brown? I do know he caved into the Realeste brokers lobby. It is harder to become a real estate broker under Gov. brown. When Gov. Scheartzenegger was hit by the Reators lobby he said, 'I'm sorry. I don't want to make the broker's license more difficult to obtain. You haven't presented one instance where the old system failed?' He vetoed the bill.
That day, I went from a militant, strict Democratic to someone who didn't care which party you were affiliated with.)
This doc is part of a series. I just skimmed the first two docs (this '101' and tthe next '102'). They do a reasonable job of introducing accounting.
I've conducted training sessions in accounting (for people whose day job is something else) at several tech firms. Two things I've found drive the points home are:
- having to make a series of debit/credit transactions (from a supplied description of stuff that has happened)
- having to work out what certain items on a balance sheet or income statement mean
It's hard to appreciate the beauty of the accounting equation until you see how the balance sheet, income statement, and cash flow statement are related.
As a Canadian CPA, CA (and also programmer), I think the difference between bookkeeping and accountancy is the need for judgement.
A bookkeeper will record transactions in designated accounts using the process that has been indicated for that type of transaction. However, the bookkeeper will not be evaluating the revenue recognition process to establish when it is reasonable to record revenue (versus deferred revenue, a liability) as a transaction relates to the standards in effect. It is also likely that the bookkeeper will not be responsible for making calls as to whether certain situations should be recorded as contingent liabilities or simple F/S note disclosures or for things like testing intangible assets for impairment.
For a typical tech startup, there are probably fewer situations that give rise to the need for an accountant than bigger, more complex entities. That being said, I suspect that many start-ups with complex cap tables are not reporting in full GAAP / IFRS conformity simply because this is likely not something required by the users of their F/S.
I had an opportunity to be the manager of a multi-million dollar contractor's office. It included bookkeeping among many other things. Never before had I realized the power of cash-flow, but also the destruction.
On paper there were many employees that made more annually than the CEO.
This may not be what the op had in mind, but I remember my first bookkeeping (mostly AR/AP/payroll) gig. Watching the books was like watching the tide. Cheques from customers seemed to come in waves, and you'd watch the bank account swell. But then, you'd do a monthly payable run and a few days later you'd enter a big payroll with the monthly expense reimbursements. All of a sudden, the funds in the bank account started to dwindle...until the next wave of cheques...
Just got back to this. But almost exactly. I'd deposit the biggest checks I've ever seen. But they'd be gone almost immediately if we zeroed the AP. It completely changed the phrase of "letting the bills pile up" for me.
For what it's worth, I never once payed a late fee. I'd pay the original amount no matter how late and never heard a word from the receiving end's AR department.
Since our product bridges the gap between bookkeeping, accounting, finance and engineering, and because this is aimed at developers, we're building the knowledge up from bookkeeping in part 1, to accounting basics in part two.
I think it's great that someone is trying to teach this topic to software engineers and I accept that it's hard to teach but I think that this document doesn't do a good job. Covering the "balancing" of debits and credits as the starting point is too abstract.
GNUCash's (which I use for my personal accounts) guide is unhelpfully down right now, but you can find it here:
The post basically read like a summary of the first class in my accounting degree. I would be very surprised if the average software engineer has less tolerance for abstraction than the average accountant.
Debits and credits are the foundation on which all of accounting is built. I don't see why you would start anywhere else.
I too depised these things when I took accountancy in school but by the second year I had accepted their value and now cannot see how else it could have been better. Debit/Credit is the foundation of double entry. Most people think accountancy = bookkeeping. They dont get Double entry system. It's understandable, it took me a considerable time to grasp it.
GnuCash is great; I credit it with changing me from a '$20 in my pocket/$0 in my pocket' guy in college to someone who's doing pretty comfortably now. It's all about understanding how money dances through a series of accounts.
I did accounting (actually bookkeeping) in high school, as did almost all my school-mates, and it is a very useful skill to have. From understanding debit and credit on a bank statement, to being able to read a balance sheet, accounting is a powerful tool in day-to-day life. South Africa has a bit of an accounting fetish (Chartered Accountants are the gods of the business world here), but it certainly is useful to know the rudiments.
We hear about coding being the "new literacy". I am sceptical, but if coding is the "new literacy" then basic accounting knowledge is equally important, in my opinion.
That's the easiest way to deal with it. If you can remember that (which is not hard), and where one type of account falls on the left/right spectrum (which isn't hard either, pick whichever you like), then you can figure out the rest.
Until you're used to these two words and they speak for themselves, assigning any other meaning tends to lead to more confusion than anything else.
I dropped accounting in my 10th grade largely because I made the mistake of trying to get into the "meaning" of debit and credit. Mnay wasted hours there.
Finally in grad school I got it - left and right - and accounting has never been a problem again.
I started going through ledger recently (after a fructuous discovery in a HN comment), and it's truly a great tool with a great documentation for someone not used to accounting!
> From a mathematical perspective, abnormal balances are essentially negative balances, though in accounting negative numbers should never be used or allowed.
This seems like a bad legacy passed down unwittingly. I am not trained in accounting, but been keeping my books for several years now. I have written a ledger-cli clone and have been using it for the last three years for both personal and company accounts. Using signed numbers works perfectly fine during book keeping. I use the Debit/Credit lingo only when I need to show reports to the pesky accountants. (Fortunately, my main accountant doesn't bother me with formalities).
Yeah, the "should" is editorializing. The avoidance of negatives is pretty easy to explain as a simple mistake. From the article:
> Luca Pacioli, often referred to as "The Father of Accounting," wrote, printed and distributed the first complete description of double-entry accounting in 1494.
> In 1545, Cardano in his Ars Magna did not allow negative numbers in his consideration of cubic equations, so he had to treat, for example, x^3 + ax = b separately from x^3 = ax + b (with a,b > 0 in both cases). In all, Cardano was driven to the study of thirteen different types of cubic equations, each expressed purely in terms of positive numbers.
> In A.D. 1759, Francis Maseres, an English mathematician, wrote that negative numbers "darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple".
Bookkeeping uses a different reasoning system than you are accustom. I think of it as vectors in a 2-dimensional space (asset/liability, income/expense) -- where each vector has a magnitude and a direction (debit/credit). You can think of "debit" being the head of the vector (where value is going), and the "credit" as being the tail (where it comes from). Transactions are paired, complementary movements in this space -- not plus/minus movement along a single line.
Visually, it's much easier to distinguish between a debit and a credit if they are in different columns. A tiny little minus sign won't do it. Of course, you could use color, but, that's not always printable. Parenthesis are OK, but, it makes sanity checks in your head difficult. Of course you could do this transformation a report if you wanted, but really, how often does that happen?
Logically, these are actually very different activities. When you debit an asset account, it's representing a kind-of-activity that happens (retained value accumulating). Once you view credit/debit as just plus/minus, you're tempted to neglect the other dimensions of the interaction. To a beginner, debit/credit affect on asset/liability/expense/income accounts seem like an unnecessary distiction, however, the interactions are inverted in their affect. Is minus good or bad? It completely depends upon your perspective.
Redundancy is a feature not a defect; it's a checksum. There's always a tendency to simplify the model and elminate the balancing interaction and check. This is possible, of course, and it does simplify the recordkeeping. However, it means that logical classification errors are harder to discover. When (perhaps big) money is at stake, why take the risk? By having 2 complementary transitions in a more complex space, you cause the person making the entry to think... and that's very useful (even if it's tedious or exhausting).
Pratically, you have convention/tradition. You're making a choice to use plus/minus for credit/debit is one of the distinctions, you could just have easily use it for asset/liability or income/expense. Why favor credit/debit? While this may not be the best way to solve these concerns, the approach is the incumbant -- most financial people expect this kind of problem to be this way, regardless of the extra complexity involved. Tradition here reduces communication overhead.
Even so, the rules arn't passed down unwittingly, they form an approach known to work. I think each generation is welcome to challenge (and they often do challenge) tradition, however, new approaches need significant justification.
> Transactions are paired, complementary movements in this space -- not plus/minus movement along a single line.
Sure, transactions are pairs (or balanced sets) of entries. Entries however, are exactly plus/minus movements along a single line in a single account. Sign (+/-) reflects that much better than debit/credit labeling does.
> There's always a tendency to simplify the model and elminate the balancing interaction and check.
Using +/- in place of credit/debit does not eliminate the balancing interaction. In fact, it makes exactly what is done in the balancing interaction more explicit.
> You're making a choice to use plus/minus for credit/debit is one of the distinctions, you could just have easily use it for asset/liability or income/expense. Why favor credit/debit?
Because income, expense, asset, and liability, are all kinds of accounts, and credit and debit are not, they are descriptors of whether an entry (or balance) is a flow (or accumulation of flow) of value into (debit) or out of (credit) an account.
> Pratically, you have convention/tradition. You're making a choice to use plus/minus for credit/debit is one of the distinctions, you could just have easily use it for asset/liability or income/expense. Why favor credit/debit?
The answer is that people intuitively understand what an asset, liability, income and expense is. People don't understand what a debit and credit is. If I deposit money in to my bank, should the 'bank account' in my accounting system be credited or debited? Most people would (incorrectly) say 'credited'.
It isn't that complicated. They key to unlocking double-entry accounting is the accounting equation and the (8?) or so rules mapping debits and credits to transactions. As for a bank deposit, it needs to be understood that the statement is produced from the bank's perspective. I don't think that the average person, given a few hours of learning, would struggle with this.
This rules are in place due to over centuries of accounting experience. It may seem unintelligent or silly to the untrained eye, "debito and credito" , exclusion of negatives or many other are in fact in existence because they work.
Thanks for the recommendation. If it wasn't $73 I'd definitely grab a copy. Why is Haskell "if you must" though? Are the others better at expressing code algebraically?
I always appreciate new ways to make accounting easier. A lot of accounting should be automated because most of it is ministerial.
But, I do thinking that financials are something that each person should learn a bit more about. I find it too common that people aren't spending enough time to understand what their financials are trying to tell them. For example, they're generate awesome revenues, but failing to convert it into cash fast enough to meet their debts (statement of cash flows).
Always a fan of everyone gaining financial literacy =).
I found that article to be rather obtuse and very complicated (I think it was an intellectual exercise rather than a primer), but that's my personal opinion. Definitely not the "light reading" GP wanted. A useful primer would, in my opinion, start with the accounting equation, explaining its components, and move on from there.
I was referring to the Martin Kleppmanm piece on "Accounting for Conputer Scientists". It seems like it was meant as an exercise in mapping accounting to graph theory, but somehow morphed into a go-to tutorial for accounting.
Looking at the comments on that website, it has even developed a sort of fanboyism. But IIRC, it led to some "interesting" insights when it was first discussed on HN, like "sales are liabilities".
I find the alleged impenetrability of basic accounting to be rather baffling in general.
Thanks, happy you were not referring to our document! :-)
Sales (Incomes) are clearly equity, with Expenses being contra-equity. Not sure how anyone could come to any other conclusion, but I'll read the article and it'll probably become clear. :-)
I've always understood it using the 'source' and 'destination' analogy that many unix tools follow.
Credit is the source while debit is the destination.
Using the source and destination keywords has the advantage of not implying the actual operation to be performed. For eg. credit results in an 'add' operation on an expense account while a 'subtract' operation on an asset account.
This is as good a place as any to mention that this double-entry bookkeeping process, a centuries-old methodology, is long overdue for replacement (but changing a global standard like this may never come to pass). In the early 1980s, an academic known as William McCarthy presented one such alternative known as REA, which organizes accounting into a resources-events-agents model. A little while ago, I asked Mr. McCarthy whether REA was dead and he claimed that it in fact wasn't dead and that work was still ongoing.
The thing is, since as early as the 1960s, there has been discussion and publications about event-driven accounting architecture. Pretty crazy, right?
Alas, considering IFRS and GAAP span the world's modern economies, it may be safe to assume that hell will freeze over before any viable accounting alternative to double-entry bookkeeping supplants it.
I don't think double-entry is going anywhere, but guidance certainly is. I pay a lot of attention to this stuff, specifically the convergence of financial accounting guidance. It's not happening at a blistering pace, but things are moving. More and more US companies are reporting under IFRS. FASB and IASB have both done a lot of rewriting in the past 5 years, which is aligning GAAP and IFRS.
APAC is really churning. Japan GAAP takes more hints from US GAAP, but many Japanese companies have opted for IFRS. Australia GAAP has some very strange principles, especially around equity compensation, but is beginning to align with IFRS. China, well, I don't
really know, but I'm definitely on the lookout for it...
I think it's one of the most interesting of uninteresting things.
I doubt double-entry book keeping will be replaced but there are many opportunities to build on it. GAAP earnings can give you results that are completely out of sync with whether a business is making it's owners richer or not which is what counts at the end of the day.
Bookkeeping wasn't super hard to figure out when I started using GNUCash in grad school. Really the most painful part was importing history from shitty local bank records.
I don't import history from my bank - I find manual reconciliation fairly quick and quite useful - but I share your pain with dealing with banks. QIF is a useless format for double entry systems.
GNUCash lets you do separate import and reconciliation steps. The problem was the bank didn't support OFX. Or maybe even QIF, it was a long time ago and I was naieve.
A neat intro for a project that looks like it could be very neat, but definitely not yet full featured enough to compete in the Quickbooks or even Ledger environment.
It's an interesting move to make the docs all google docs, but for readability it really is quite nice!
Your homepage talks about great handling of micro-transactions but I can't find ANYTHING about it in the docs. Can you point me to something?
I've studied accounting at school and I've always hated it since then.
To me, accounting is a data model gone wrong. Redundancy, race conditions, unclear semantics, too generic...
I've tried countless times to make sense of it (the latest being today when I read the post with great hope), but I always came to the same conclusion: there must be a better way.
Yet I know the value of the model as a log to record transactions.
We're all confronted to accounting (when we read our bank ledger)... Ask the public, and they'll tell you it's good if there's more money in the credit column than the debit column. This "common wisdom" is false in accounting. What's a debit card? a credit card? What's an account? Isn't it a container for money? not for accountants.
Accounting turns many concepts upside down... and I always fail to bend my mind enough to grasp it.
I admire accountants for succeeding where I fail so miserably, but they're also responsible for the problem. There must be a better way... I was so bad in accounting at school...
> Ask the public, and they'll tell you it's good if there's more money in the credit column than the debit column.
That's because the public is used to hearing the terms used by entities who are using them in the accounting sense, but where the member of the public in question is external to the entity whose accounting the term refers to.
So credit -- and outward flow of value -- sounds good, because when the public hears it from another company, its usually because they are the sink to which value is flowing (and debit -- an inward flow -- sounds bad, because the member of the public hearing an external entity use the term is usually the source from whom the value is flowing.)
Of course, neither is intrinsically good or bad, they are good or bad relative to a particular actor based on whether the account they refer to is internal or external to the actor. Debit is just inward flow of value to an account, credit is outward flow of value from an account.
> What's an account? Isn't it a container for money?
That's not a bad approximation; a better approximation would be "a named accumulation of flows of value".
> Accounting turns many concepts upside down... and I always fail to bend my mind enough to grasp it.
Interestingly, all the concepts you list that the public perceives in a way which you seem to think conflict with the accounting view actually reflect limited subsets of the accounting view from a narrow perspective, which are subsumed within the more general view of accounting.
Accounting doesn't turn them upside down, it just broadens them.
So sorry we couldn't get you across the finish line -- you seem to be right in our target audience. :-(
> To me, accounting is a data model gone wrong. Redundancy, race conditions, unclear semantics, too generic...
I felt this once (though don't see the race conditions) but I now know there is no redundancy, the semantics are very good, and the genericity is a gigantic benefit.
John and at appreciate all the discussion and feedback.
We're absolutely delighted to have struck a chord with developers, the intended audience of this piece, and with accountants, who have managed and passed down this technology for 700 years.
We're working through the backlog of comments and will reply where we feel we can add some value.
>with developers, the intended audience of this piece,
I'm not sure why you feel the document targets developers specifically. I didn't see any text that's a unique bridge to a developer's perspective.
For example, a text for "developers" might include examples of video game "tokens" or multi-player "weapons" that can be traded. You'd outline a rudimentary outline of what data structure to keep track of the source and destination of where the tokens went.
Or an example would be bitcoin money being subtracted and added to various accounts. Since many developers know bitcoin, maybe map bitcoin ledger concept to accounting concepts. Or explain how they are radically different.
Your current document is a generic introduction and one can search & replace "for developers" to "for biologists" and nothing else would have to change.
Thanks for your feedback. We felt it was for developers are we're developers and this is the way we've come to describe and understand it having built Subledger.
Your point is excellent and we'll steer toward developers in the future.
It's funny: I had to write this stuff back in 1985. After that, we did reports and special inventory breakdowns added onto an existing 3rd party system. Still, I guess it helps to know where projected purchases and sales are being logged.
Essential knowledge, so when your average clueless buisness major tryies to get you to come up with new metrics and wont buy into other previous useless metrics (codelines checked in etc.) you can invent something funny, that allows you to go back to "real" work. Success never had trouble getting Alimoney-suits.
It means it's teaching (or attempting to teach) the field of accounting using terms, concepts, and styles of thinking familiar to developers, instead of starting from square 1.
Though the headline is obviously doing its job, I'm just not willing to swallow the presupposition that developer people exist in the same way that male and female exist or that Asians exist. Developers as they are called are just people with a range of skills, and the same goes for accountants. I even heard a good accounting school has a program for accountants with a proclivity for programming.
I admit the title isn't absolutely fascist, racist, or sexist, but it is some kind of ist, and it is annoying. Maybe accountants, with self congratulatory pride in their profession, feel the urge to divide the world up into neat little categories?
Are you suggesting that nobody should class themselves as a developer, and/or that as self-identified developers, who I can agree are just people with a range of skills (and I never suggested otherwise), we should not attempt to write a document attempting to explain accounting to other self-proclaimed developers, who, in our decades of experience, tend to have certain viewpoints, vocabulary, and interests in common?
Finally, while I'm delighted that you agree the title isn't absolutely fascist (which you never claimed in the original post and suggest in your response it to be partially), racist or sexist, I'm entirely baffled as to why you felt compelled to post a comment stating it in absolute terms in the first place.
Did you say decades of experience? Oh. Ok. Nevermind.
I'm just asking myself why not write about accounting, and let the reader decide what group he or she belongs to. The answer is clearly something like, we need a good title.
Now replace Yin with Debit and Yang with Credit, and that's mostly it.