Why are you using the wrong licence?

I frequently see posts/articles/screeds asking why people don’t contribute to open source. If it’s important that recipients of open source software contribute upstream, and you are angry when they don’t, why use licences like MIT, Apache, GPL or BSD that don’t require upstream collaboration?

Back in the day, Apple released their public source code under version 1 of the Apple Public Source Licence, which required users who changed the source to fill in a form notifying Apple of their changes. You could do the same, and not be angry.

Stop ignoring the world

Long term readers will have noticed, and everybody else is about to be told, that this blog has had posts in the Responsibility category since 2010. I’m not rigorous in my use of WordPress categories, but it’s not much of a stretch to assume that most of those 40 posts touch on professional ethics, and that most of the posts on ethics in this blog are in that category.

In recent times, the idea that maybe the world of computing should take its head out of its butt and consider its impact on wider society has escaped the confines of goggle-eyed loon practitioners like yours truly and hit the mainstream. In the UK, newspapers call for change: the leftist Guardian writes “Big tech is broken”, and liberal centrist paper the Independent tells us that “Those of us with any sense of morality should hate Apple“. Editorials document how social media platforms, decrying fake news while running ads for anyone with the dollars, have supplanted democratic rule with new, transnational, shareholder-run government. They show how the new unicorn startups achieve their valuations by disrupting labour law, reversing centuries of gains in workers’ rights by introducing the neoserfdom of gig economies and zero-hour contracts.

Software is eating the world, and turning it into shit. You can no longer pretend that it isn’t happening, and that you are not playing a part. That supporting the success of your favoured multibillionaire transnational platform vendor isn’t helping to consolidate ownership of society among the multibillionaire platform vendors. That your part is just making the rockets go up, and that where they come down is a different department. That your job is not a position in society and without consequence.

My platform is no platform

I currently use three of the desktop computing platforms (Windows, macOS and GNU/Linux) and one of the mobile computing platforms (Samsung-flavoured Android); I currently get paid to develop software for “the web”, an amorphous non-platform that acts in many ways like a vendor platform orthogonal to those just mentioned. This is not because I want to ally myself to any or all of those platforms but because I want to be practically independent of all of them. This is where I try to understand why.

A code of ethics

As a member of the ACM I have committed to act in accordance with the ACM Code of Ethics and Professional Conduct, or to revoke my membership. I believe that a lot of my unwillingness to buy into these platforms (and by extension, as a software professional, my unwillingness to push them on others by building upon them) can be expressed in terms of these codes.

Of course, this is expression within my interpretation of the terms. I don’t believe that Google’s data harvesting activities are consistent with the ACM Code of Ethics, but a previous ACM president was Vint Cerf, a Google employee. Clearly we disagree on our application of the Code to Google’s activity. Neither of us is, without further analysis, [in]correct; ethical decisions will be situated in a cultural and experiential context.

This, in general, is why American technology companies find it hard to expand their operations to Europe; the framework in which their actions will be viewed and judged is different.

App stores and the introduction of dependence

The iOS platform is locked down to most people, in three ways: technologically (a cryptographic system prevents all but specific native software and arbitrary JavaScript from being run); market control (only Apple can add software to the approved list; only paid members of their developer program can propose software for approval) and socially (the norms among developers, both native and web software, follow the “don’t make me think” principle in which applications are simplistic and unextensible, as discoverability and ease of use are valued over flexibility or composition).

The same argument applies to Google’s Chrome OS and Microsoft’s Windows 10 S.

This situation promotes an “Apple knows best” effect in which use of a computer is a passive consumption activity where the only applications available are those deemed fit to publish by the central actor, much like broadcast television.

In a professional community that previously gave us Mindstorms and Smalltalk in the Classroom, it is hard to accept that such a prescriptive model of computing is considered tolerable. Indeed, it seems at odds with an ethical imperative to improve public understanding of computing (section 2.7 in the ACM Code). It also seems to produce a three-tier system, in which those who have (the platform operators) are at the top, those who have means (ISVs who can buy into the approval system) are a rung down – albeit in a feudalistic vassal state that seems akin to coal miners buying their picks from the mine owners – and everyone else is below them. This would not seem consistent with an imperative to be fair (section 1.4 in the Code). Indeed I would go as far as to say that putting most of the people interacting with a software system into subject positions does not contribute to society or human well-being (section 1.1).

The web and “cloud” as protection rackets

If I use a web-based software application, it will probably offer to store all data on its developer’s servers (or more accurately on virtual machines run on the developer’s behalf by some service provider). It may not, indeed probably won’t, offer an alternative. My ongoing use of the application is predicated on my ongoing acceptance of the developer’s terms and pricing structure. The collection of individuals and organisations with whom my data is shared are also subject to change at any time, and I either demur or stop using the service.

But because their “service” also includes exclusively providing access, even to me, of what I created using their application, even accessing the things I already created is subject to their licence and my acceptance of their future changes, which can’t be known (and will probably be hidden up front, even where they are already being planned). This does not seem honest nor trustworthy (section 1.3 of the Code), nor to provide comprehensive and thorough evaluations of the impacts of the system (section 2.5), nor to credit my intellectual property in creating the things that are ransomed by their service (1.6).

This is fine

The BBC micro:bit is a tool for introducing young people to programming. It’s a little embedded computer with a few inputs and a matrix of LEDs for output, as well as some control lines. In principle it’s quite easy to use, I made a 1d6 simulator:

from microbit import *
from random import randint

class Die:
    ONE = Image("00000:"
                "00000:"
                "00900:"
                "00000:"
                "00000")
    TWO = Image("00000:"
                "09000:"
                "00000:"
                "00090:"
                "00000")
    THREE = Image("00000:"
                  "09000:"
                  "00900:"
                  "00090:"
                  "00000")
    FOUR = Image("00000:"
                 "09090:"
                 "00000:"
                 "09090:"
                 "00000")
    FIVE = Image("00000:"
                 "09090:"
                 "00900:"
                 "09090:"
                 "00000")
    SIX = Image("00000:"
                "09090:"
                "09090:"
                "09090:"
                "00000")
    ALL = [ONE, TWO, THREE, FOUR, FIVE, SIX]
    @classmethod
    def throw(self):
        return self.ALL[randint(0,5)]


display.show(Die.ALL, delay=100, wait=False, loop=True)

while True:
    if button_a.is_pressed():
        display.show(Die.throw())
    elif button_b.is_pressed():
        display.show(Die.ALL, delay=100, wait=False, loop=True)

Simple (I mean, simple if you know what the word randint means (hint: it means “random integer” as long as you know what an integer is), that programming languages that aren’t Fortran call the first element of an array element zero, even though it’s obviously ONE as far as a die is concerned, and you’re OK with the word classmethod).

Here it is in action: woo! I AER PROGRAMMER!!!

And here’s the litany of things I did to get there:

  • I opened the “details.txt” file on the micro:bit, which tells me a load of build numbers and flash dates. I don’t know what I’m supposed to do with that. This is hard.
  • I opened the “microbit.html” file on the micro:bit, which redirects me to microbit.co.uk, which tells me that as part of the BBC’s restructuring of its online content, I will be redirected to microbit.org. I decided this was probably OK, and ended up looking at the same site but with a different URL (whatever one of those is).
  • I clicked on the introductory video and was told that I need an Adobe Flash Player, whatever one of those is.
  • I eventually found enough buttons to find a website that is a python editor that lets me write code for my micro:bit, and a tutorial for writing Python for the micro:bit. I know what a python is, but do not know why I would want a snake for my micro:bit.
  • The tutorial tells me to use a thing called a “mu”, which is apparently not the website python editor but is another python editor. I do not know what a mu is, but I must download it.
  • There are three different download buttons, depending on whether I have a Windows, a Mac, or a Linux, whatever they are.
  • If I have a Windows, then I to enable the REPL (whatever that is) I must download a serial driver (whatever that is).
  • The driver site tells me that if I have a Windows 10 (whatever that is), then I should not download the serial driver.
  • If I have a Mac, then the first time (but maybe not other times, that’s not clear) I open the mu I have to right click it.
  • If I have a Linux, then I must chmod u+x the mu and make sure my user (isn’t that me?) is in the dialout (whatever that is) group (whatever that is).
  • Now I can write my python. To put it on the micro:bit, I must “flash” it. I guess that is because I have an Adobe Flash Player from earlier.
  • The micro:bit shows me helpful messages when I get something wrong. It scrolls the message “id=41 SyntaxError: invalid syntax” when I flash my python. I do not know what this means, but I was told that it’s helpful. Therefore I am stupid.

I am not singling out the BBC, the micro:bit makers, the mu creators, Microsoft, or any of the other individuals or organisations involved with creating this easy-to-use educational environment. This is fine. This is how computers work, nay this is how computers work when we are making it easy to work them. This is our industry.

To quote Freddie Mercury: is this the world we created? We made it on our own. Is this the world we devastated, right to the bone? If there’s a God in the sky looking down what can he think of what we’ve done to the world that we created?

I fix things for a living

Previously, on SICPers, I wrote that I make mistakes for a living. But making mistakes is no good if nobody’s cleaning up after them, so I also fix things. Whatever gets in my team’s way, it’s my responsibility as their lead to make sure that it’s no longer in their way.

Whether it’s a process we instituted that slows us down, some technical debt that gets in the way of new development, or some infrastructure not behaving itself, it needs to go, and I either need to clear it out or find somebody to do it for us. On my team I’ve been nicknamed “Mister Fix-It” as a result of my policy of getting rid of everybody else’s impediments before doing my own work, and we even have a Fix-It support queue just like our customer support queue. Except it’s not our customers I’m supporting, it’s my colleagues. Tickets in my queue range from “this script doesn’t handle this case and did the wrong thing when I tried to do a build” to “merge these three repos into a monorepo”. It doesn’t matter, it’s in our way, so it needs shifting.

Or does it? Is it, in fact, in the way, or are we solving the wrong problem? Some of the tickets in the Fix-It queue magically transmogrified from “Fix This” to “Measure This”: let’s discover where the problem really is before we solve something else.

No, you can’t ignore politics

I wrote, a couple of years ago, about the fact that you can’t ignore ethics in software engineering. Your software is built for a reason, it’s used for a reason, you need to be aware of those reasons and whether you’re supporting or enabling them.

That goes for politics too. That hacker news declared this week to be politics-free week shows an immaturity and unprofessionalism that makes it a dangerous place to learn about making software from. Making software is the act of some people producing things for other people, it is inherently a political act. Choosing a framework or programming language is political. Attending a meet-up is political. Being paid is oh-so-political. Publishing your side project under an OSI-approved licence? The OSI is a political organisation, the courts that will determine whether the terms of your licence are binding are political, the officials of those courts are selected by a political process.

And, anyway, let’s have a look at the front page of hacker news now, roughly five days into their politics-free week.

What they probably mean is not “political stories are off-topic”, but that political stories that stray from the default politics are off-topic. Anything that doesn’t sound like I agree with it must be subjective, whereas things I agree with are objective. Just as the default narrative in society is often white, male and affluent, so it is those things in the Valley and neolibertarian. Anything else is just politics.

I make mistakes for a living

As a team lead, my job is to make all the mistakes on my team. I’m responsible for each one of them. I’m also responsible for deciding what we do about them, whether that’s to ensure that they can’t happen again or ignore them because they’re easy to recover from.

That time someone on my team built a feature that didn’t ship because of a bug? I could have made sure the requirements were clearer, or they had more access to the product owner, or a more useful design review, or a more useful code review, or a better test plan. Or all of those, or none of those, or something else. I could have – should have – got the problems out of their way.

They don’t make mistakes, I do.

Learning about software freedom

On the front page of Hacker News at the moment is a post on The Three Software Freedoms. It does away with the Free Software Foundation’s Freedom Zero:

The freedom to run the program as you wish, for any purpose.

On the basis that it “is just silly I mean of course I can use the program as I wish.” Of course you can. Except, of course, that’s not in fact true, and because software companies are licensing – not selling – you software, you’re actually bound by their terms and the limitations they impose. Picking just one example, here are some snippits from the Apple Licensed Application End-User License Agreement, relevant to apps bought (sorry, licensed) through the iTunes App Store:

The Products transacted through the Service are licensed, not sold, to You for use only under the terms of this license

The licensor (“Application Provider”) reserves all rights not expressly granted to You.

This license granted to You for the Licensed Application by Application Provider is limited to a non-transferable license to use the Licensed Application on any iPhone or iPod touch that You own or control and as permitted by the Usage Rules set forth in Section 9.b. of the App Store Terms and Conditions (the “Usage Rules”). This license does not allow You to use the Licensed Application on any iPod touch or iPhone that You do not own or control, and You may not distribute or make the Licensed Application available over a network where it could be used by multiple devices at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Licensed Application. You may not copy (except as expressly permitted by this license and the Usage Rules), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, or create derivative works of the Licensed Application, any updates, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or to the extent as may be permitted by the licensing terms governing use of any open sourced components included with the Licensed Application).

If You breach this restriction, You may be subject to prosecution and damages.

Your rights under this license will terminate automatically without notice from the Application Provider if You fail to comply with any term(s) of this license. Upon termination of the license, You shall cease all use of the Licensed Application, and destroy all copies, full or partial, of the Licensed Application.

You agree that any Services contain proprietary content, information and material that is protected by applicable intellectual property and other laws, including but not limited to copyright, and that You will not use such proprietary content, information or materials in any way whatsoever except for permitted use of the Services. No portion of the Services may be reproduced in any form or by any means. You agree not to modify, rent, lease, loan, sell, distribute, or create derivative works based on the Services, in any manner, and You shall not exploit the Services in any unauthorized way whatsoever, including but not limited to, by trespass or burdening network capacity. You further agree not to use the Services in any manner to harass, abuse, stalk, threaten, defame or otherwise infringe or violate the rights of any other party, and that the Application Provider is not in any way responsible for any such use by You, nor for any harassing, threatening, defamatory, offensive or illegal messages or transmissions that You may receive as a result of using any of the Services.

You may not use or otherwise export or re-export the Licensed Application except as authorized by United States law and the laws of the jurisdiction in which the Licensed Application was obtained. In particular, but without limitation, the Licensed Application may not be exported or re-exported (a) into any U.S. embargoed countries or (b) to anyone on the U.S. Treasury Department’s list of Specially Designated Nationals or the U.S. Department of Commerce Denied Person’s List or Entity List. By using the Licensed Application, you represent and warrant that you are not located in any such country or on any such list. You also agree that you will not use these products for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons.

So don’t claim, through malice or ignorance, that Freedom Zero is not worth making explicit, and doesn’t need protecting.

The Vexing Problems in Programming

I admit it, I’ve been on the internet for quite a while (I could tell you that my ICQ number is 95941970, but I haven’t logged in for years) and my habits haven’t changed. I still regularly get technology news from slashdot, and today was no exception. An interesting article was Here Be Dragons: The 7 most vexing problems in programming. Without wanting to spoil the article for you by giving away the punchline, there are indeed some frustratingly difficult problems mentioned: multithreading, security, encryption are among the list.

All of these problems are sideshows to what I see as one of the largest and most vexing issues in programming: the fundamental rule to business administration is that your income should be greater than your costs, but software makers still, by and large, don’t have a way to compare the expected value of their work to the expected cost of the work.

The problem in space

Different software teams – and individuals – do work in different contexts, and in different ways. The lone wolf micro-ISV is not the same as an individual contract developer. The in-house IT team does not have the same problems to solve as the shrinkwrapped software vendor, and those developing web services for public consumption have yet another context. The team with core hours all working in a single office is different from the distributed team inhabiting multiple time zones.

How much of this variety is essential, and how much is accidental? How much of it is relevant, when considering some intervention, process change, or technique? Consultants speaking at conferences (another context with its own similarities and differences from the others) don’t tend to talk about what researchers in fields such as psychology would recognise as “threats to validity” of their work, but given all of the ways in which software is made, we need to know whether some proposal applies to all of them, or to some of them, or whether it has been applied to some of them and might be applied to others, and what would assist or confound that application.

The problem in time

What are the accepted, tested and validated ways to identify who will be using and otherwise impacted by our software systems? To know whether they can use the system we propose, and whether it is the best system for their intended use? To ensure that our proposed software systems treat those people ethically? To understand the cost (to ourselves and to others) of constructing those systems? To deliver the systems to the people who will interact with them? To choose which people are or aren’t entitled to access? To build a representation of the problem to be solved, to validate that representation, to validate the solution against that representation?

Where an answer exists to those questions, what are the contexts in which it is valid and what are the threats to its validity? How has that answer been compared with other possibilities? How has it been confirmed? How has it been challenged? How can I find out about those confirmations and challenges? How can I find out about any alternatives? What techniques exist to weigh up those alternatives quantitively, rather than relying merely on the persuasiveness of the conference speakers promoting those solutions (and, by the way, the books/screencasts that describe the solutions)?

The lack of a problem

Why should I care? There’s enough money in software at the moment to mean that I don’t need to be any good at knowing what works or doesn’t work, I just need to get out there and sell some software. In the rare situation that I don’t make my money back, that’s just the market forces at work, and I can go and get a high-paying job somewhere while I lick my wounds, and pick another programming language/framework/platform/whatever it is that’s going to make my next attempt definitely succeed.

Clearly, this bottomless pit of money that arises from society’s unwavering faith in software and its ability to cure all ills is never going to run out. There’s no need to worry ever about whether we’re doing it right, because there’ll always be someone out there willing to pay for us to do it wrong. Life as a programmer is like some kind of socialist utopia where whether we’re making a valuable contribution or not, the rest of society is looking out for us.

That’s going to last forever, right?

The Principled Programmer

[Note: this post represents the notes made for my talk at iOS Dev UK 2014. As far as I’m aware, the talk isn’t available on the tubes.]

The Principled Programmer

The first thing to be aware of is that this post is not about my
principles. It’s sort-of about your principles, in a way.

On dichotomies

Let’s look at two games. You may not have heard of Chaturanga (unless
you practice yoga, but I’m talking about a different Chaturanga), but
it’s the ancient game that eventually evolved into Chess.

You may not have heard of Nard either, but it’s a very different game
that grew up into Backgammon. There’s a creation myth surrounding
these two games, that says they were invented at the same time. Some
leader thousands of years ago wanted two games; one a game of skill
and the other a game of chance.

The thing is, you can lose at chess by chance: if you happen to be
having an off day and miss a key move that you’d often
make. Similarly, you can lose at backgammon through lack of skill: by
choosing to move the wrong pieces.

We were presented with two options: skill (chaturanga) and not-skill
(nard). However, the games do not actually represent pure states of
the two concepts; they’re more like a quantum system where the
real-world states can be superpositions of the mathematically “pure”
states.

All of this means that we can’t ignore states in-between the two
poles. Such ignorance has a name in the world of critical analysis:
the fallacy of the excluded
middle
.

That is not the situation we have in bivalent logic, including the
mathematical Boolean formulation frequently used to model what’s going
on in computers. This has the law of the excluded
middle
, which
says that a proposition must either be true or false.

In this case, the fact is that the two propositions (you are playing a
game of skill, or you are playing a game of chance) do not exactly
match the two real possibilities (you are playing chaturanga, or you
are playing nard). There’s a continuum possibility (you are using some
skill and some chance), but a false dichotomy is proposed by the
presentation in terms of the games.

On rules

The existence of a rule allows us to form a bivalent predicate: your
action is consistent with the rule. That statement can either be true
or false, and the middle is excluded.

This means we have the possibility for the same confusion that we had
with the games: compliance with the rule may be bivalent, but what’s
going on in reality is more complicated. We might accidentally exclude
the middle when it actually contains something useful. Obviously that
useful thing would not be in compliance with the rule. So you can
think about a rule like this: a statement is a rule when you can
imagine contraventions of the statement that are of no different value
than observances of the statement. Style guides are like this: you can
imagine a position that contravenes the rules of your style guide
that is of no lesser or greater value: following another style
guide.

Of course, the value of a style guide comes not from the choice of
style, but from the consistency derived from always adhering to the
rule. It doesn’t matter whether you drive on the left or the right of
the road, as long as everybody chooses the same side.

One famous collection of rules in software
engineering is Extreme Programming. Kent Beck described hearing or
reading about various things that were supposed to be good ideas in
programming, so he turned them up to eleven to see what would
happen. Here are some of the rules.

  • User stories are written. It’s easy to imagine (or recall)
    situations in which we write software without writing user stories:
    perhaps where we have formal specifications, or tacit understandings
    of the requirements. So that’s definitely a rule.

  • All production code is pair programmed. The converse – not all
    production code is pair programmed – poses no problem. We can imagine that the two conditions are different, and that we might want to choose one over another.

Rules serve two useful functions, of which I shall introduce one
now. They’re great for beginners, who can use them to build a scaffold
in which to place their small-scale, disjoint bits of knowledge. Those
bits of knowledge do not yet support each other, but they do not need
to as the rules tell us what we need to apply in each situation.

The software engineering platypus

Having realised that our rules are only letting us see small pieces of
the picture, we try to scale them up to cover wider
situations. There’s not really any problem with doing that. But we can
get into trouble if we take it too far, because we can come up with
rules that are impossible to violate.

A platitude, then, is a statement so broad that its converse cannot be
contemplated, or is absurd. Where a rule can be violated without
hardship, a platitude cannot be violated at all – or at least not
sensibly.

The problem with platitudes is that because we cannot violate them,
they can excuse any practice. “I write clean code”: OK, but I don’t
believe I know anybody who deliberately writes dirty code. “This
decision was pragmatic”: does that mean any other option would be
dogmatic? But isn’t “always be pragmatic” itself dogma?

Platitudes can easily sweep through a community because it’s
impossible to argue against them. So we have the software
craftsmanship manifesto, which values:

  • A Community of Professionals. As any interaction
    between people who get paid comes under this banner, it’s hard to see
    what novelty is supplied here.

  • Well-Crafted Software. Volunteers please for making shitty
    software.

The Principled Programmer.

There must be some happy medium, some realm in which the statements we
make are wider in scope, and thus more complex, than rules, but not so
broad that they become meaningless platitudes that justify whatever
we’re doing but fail to guide us to what we should be doing.

I define this as the domain of the principle, and identify a principle
thus: a statement which can be violated, where the possibilities of
violation give us pause for thought and make us wonder about what it
is we value. To contrast this with the statements presented earlier:

  • violate a rule: meh, that’s OK, the other options are just as good.

  • violate a platitude: no, that’s impossible, or ludicrous.

  • violate a principle: ooh, that’s interesting.

Coming up with good principles is hard. The principles behind the
agile manifesto contain some legitimate principles:

  • Our highest priority is to satisfy the customer through early and
    continuous delivery of valuable software. Interesting. I can imagine
    that being one of many priorities of which others might be higher:
    growing the customer base, improving software quality, supporting what
    they’re using now and deferring delivery of new software until it’s
    needed. I’ll have to think about that.

  • Working software is the primary measure of
    progress. Interesting. This seems to suggest that paying off technical
    debt – exchanging one amount of working software for another amount of
    working software over a period of time – is not progress. I’ll have to
    think about that.

But then it also contains rules:

  • Deliver working software frequently, from a couple of weeks to a
    couple of months, with a preference to the shorter timescale. We ship
    a couple of times a day, and I don’t feel that’s worse.

  • Business people and
    developers must work together daily throughout the project. Is there
    anything wrong with every other day?

And platitudes:

  • Build projects around motivated individuals. Give them the
    environment and support they need, and trust them to get the job
    done. I cannot imagine a situation where I would hire people who do
    not want to do the work.

  • Continuous attention to technical excellence and good
    design enhances agility. This is tautological, as technical excellence
    and good design can be defined as those things that enable our goals
    and processes.

Why is it hard? I believe it’s because it’s highly personal, because
what you’re willing to think about and likely to get benefit from
thinking about depends on your own experiences and interests. Indeed
I’m not sure whether I want to define the principle as I have done
above, or whether it’s the questions you ask while thinking about
the validity of those things that are really your principles.

## Nice principles. Now go and turn them into
rules.

The thing about thinking is that I don’t want to do it when I don’t
need to. My currency is thought, so if I’m still thinking next year
about the things I was considering this year, I’m doing it wrong.

Principles are great for the things that need to challenge
the way we work now. But they should be short-lived. Remember the
beginner use of rules was only one of two important contexts? The
other context is in freeing up cognitive space for people who
previously had principles, and now want to move on to have new
principles. In short-circuiting the complex considerations you
previously had, mentally automating them to prepare yourself for
higher-level considerations.

Notice that this means that it’s a rule in isolation that doesn’t cause us any problems to violate. It may be that the rule was derived from a principle, so some thought went into its construction. Without that information, all we can see is that there are two possibilities and we’re being told that one of them is acceptable.

The challenge that remains is in communication, because it doesn’t
help for the context of a rule to be misidentified. If you’re a
beginner, and you describe your beginner rule and someone takes it as
an expert rule, they might end up talking about perspectives that
you’re not expecting. Also if you’re an expert and your expert rule is
perceived as a beginner rule, you might end up having to discuss
issues you’ve already considered and resolved.

So by all means, identify your principles. Then leave them behind and
discover new ones.