Design a site like this with WordPress.com
Get started

Do Not…

I recently found myself doing a lot of stupid things, in rapid succession, so I thought I’d jot down a few “do not” style commandments. The context here is software development 馃檪

Do not develop a subsequent feature, until the previous feature is in production use.

Do not code a feature that seems odd to you, until you’ve clarified it thoroughly with the business.

Do not discuss more with the business, beyond what you can develop between now and your next meeting.

Do not both manipulate and migrate data at the same time. Either manipulate the data first, then migrate it. Or migrate the data as-is, and then manipulate it afterwards.

A process that somebody has to wait for will inevitably generate questions like: how much is there to do, how much has it done, how much longer will it take, which step is it in, etc. Do not build a process that people have to wait for, without also building some modicum of observability in, so that they can answer these sorts of questions for themselves.

Do not plan based on people’s principles. People do not have principles, they only have preferences. As soon as the situation changes, and their old “principles” are no longer useful, then their new preferences will be re-ordered, and their old “principles” will be updated.

Do not ignore warnings or errors that you don’t understand. Figure them out, and then get rid of them.

Advertisement

Kinds of Conflict

I think if you clarify the kind of conflict you have with somebody, then it can help you better allocate resources in combating them. If you have a political conflict, then likely political resources will be easier and more applicable to beat them. If you are in a physical conflict, then only physical violence (within the rules of the game) will accomplish much. Knowing what sort of conflict you’re in can help you figure this out.

I think a lot of people think they are in a political conflict, when they’re really in a cultural conflict. These folks use political means, such as battling over elections, when the entire society is moving out from underneath them.

Spiritual Conflict 路 You’re on opposing sides of a battle that exists beyond our present understanding of time and space.

Physical Conflict 路 One or both of you is presently trying to do physical harm to the other one.

Cultural Conflict 路 You disagree about fundamental aspects of how a society should operate.

Social Conflict 路 You are both competing for scarce social credit resources: friends, time with certain people, esteem, speaking time, etc.

Political Conflict 路 Within the present political frame of reference, you disagree about what you want. You’re voting on the same thing differently. You both agree to the political framework, and are operating within it.

Arms-Length Conflict 路 A kind of business conflict where there is no way for you to do better, without the other side doing worse. There is a pie of a fixed size, and if you get a bigger slice, they necessarily get a smaller slice.

Business Conflict 路 They’re a competitor, and you’d prefer your business thrive, while theirs falters.

Things That Aren’t Journalism

The words “news”, “journalism”, “journalist”, “reporting” should have stricter definitions. I’m painting the below in broad strokes. Obviously, there are exceptions and special circumstances and mitigating context. But also obviously, a lot of media sources clearly and unambiguously fall into these non-journalism buckets. A lot of media isn’t journalism, and that’s fine. Nobody expects an entertainment publication like Popular Mechanics to publish an article claiming that some new technology is boring and unlikely to amount to much. That’s fine as that publication is not meant to be journalism, it’s understood to be fun. Great! The grief is that so many publications are erroneously claiming to be “journalism” when they most clearly are not at all.

  • A publication that quotes unnamed sources is gossip, not journalism.
  • A publication that doesn’t publish retractions when they’re wrong, timely and prominently, is propaganda, not journalism.
  • A publication that doesn’t publish at least two opposing viewpoints, side by side, on each important topic, is entertainment, not journalism.
  • A publication that routinely hires and promotes a large proportion of ex-members of a particular government, business, or sector of the economy, is a mouthpiece, not journalism.

Computer vs. Human Time

I got interested in comparing the experience of human time to computer time. I didn’t double verify the exact numbers below. Take it with a grain of salt. I think it’s interesting, if only from a sci-fi perspective.

Computer InformationComputer TimeHuman TimeHuman Information
1 CPU cycle0.3 ns1 sAdd two small numbers in your head
Level 1 cache access0.9 ns3 sA number scribbled in the margin of a piece of paper
Level 2 cache access2.8 ns9 sSomething written a few pages away
Level 3 cache access12.9 ns43 sA term you have to look up in the index at the back of the book
Main memory access120 ns6 minSomething you wrote in your notebook, but aren’t sure exactly where
Solid-state disk i/o50 碌s2 daysA book from the local library
Rotational disk i/o1 ms1 monthA book you have to research, find, order, and have mailed to you
Internet: US East to West40 ms4 yearsSomething you have to get a college degree to learn
Internet: North America to Europe81 ms8 yearsSomething you learn after starting your career
Internet: North America to Australia183 ms19 yearsSomething you learn after a career spent in the field
Virtual OS reboot4 s423 yearsIt takes generations of people to figure this out
Physical system reboot5 m32 millenniaSince the time people were hunter/gatherers
Modern home computers, 1980s to 2020s40 y40,000 millenniaLonger ago than the Earth itself even exists

I’m not exactly sure where the original source for this is, but here is an example: Here鈥檚 a neat trick for understanding how long computer processes take.

Pragmatic Null

I’m still working to embrace strict null in C#. In the mean time here are a few notes on how I try to deal with null today.

Avoid null as a sentinel value. Sentinel values are really just a specific example of the more general “magic number” anti-pattern. Magic numbers are bad enough in general. At least a magic number like -1 doesn’t tend to accidentally appear. However, magic values like 0 and null are easily set accidentally.

If you really need to communicate something complicated back to the caller, then return a data structure with better semantics. Languages like Python and Go make this easy because their functions can return multiple values or use tuple unpacking. C# doesn’t have those features, so you will need to define a class or struct to hold the values you need to explain to the caller. Still it is better than using magic numbers to communicate.

Specifically for lists, dictionaries, and other data structures, returning an empty structure is often better than returning null. Functions can often be chained together in pipelines, and some of the functions in the pipeline might not accept null. Usually, they will happily accept empty data structures.

A null value is usually more obviously “blank” than an empty string. Unless an empty zero length string actually has semantic meaning to your context, it’s probably best to just return null.

Accept null values whenever possible. This is a more specific case of Postel’s Law: be liberal in what you accept, and conservative in what you send. If somebody passes in null, treat that as an empty value, as far as you can. Try not to throw an exception.

Certainly, if a null value is an error in your context, then by all means throw an exception.

In C# you can quickly turn a null value into a reasonable default by using the ?? operator.

If null or empty is a reasonable value for your semantics, then go ahead and return it. For example if you have a search function, and the caller searches for something that doesn’t match anything, then returning null is fine. Especially if they pass in null, then return null. SQL makes good use of this principle with its “three-valued logic”. Propagating null through the system, rather than throwing exceptions, can often make the most sense.

Software Development T’s

Talk about how it’s going. What else we could do?
Think about next steps. How could technology help?
Tap tap tap. The developers bang away on their keyboards.
Try it out. What do you think? Is this better?
Turn it to production for end users.

Include Everyone

I was recently asked an uncomfortable question: “I already gave you this information, why are we meeting again?” Ouch. The truth hurts. I had made a mistake. Hint: my mistake is the last item in this list. TL;DR: When inviting people to cooperate on a task, make sure you invite everybody who is involved.

Different communities sometimes disagree on things. If you only meet with some folks, then you might get answers that other folks aren鈥檛 on board with. You鈥檒l think everything is okay, until they hear about it, and then you’ll find out you’ve stepped on a trap.

Different communities sometimes have friction with each other. This might not have anything to do with what you鈥檙e doing, so you might not know. Putting them in front of each other can bring up topics and issues that are bigger than just your project. You might want to know about this context early on, before you get too far into what you鈥檙e doing. It could end up being relevant.

Sometimes communities are hiding from each other, and want you to serve as a go-between them. That’s probably not your job. If you serve as the diplomat, then you’ve taken on an additional new role. Communicating between teams is a whole job, all by itself. Do you really want that additional burden?

Hearing multiple communities talk about the same things is one of the best ways to dig up differences in terminology. Domain Driven Design teaches us to always be on the hunt for a single 鈥渦biquitous language鈥. Having everyone talk to each other really helps shine a light on differences in language. Can you get everyone to agree on a single definition for each term?

If you make progress without one group on board, then you run the risk of finding out later that you missed something. Even if nobody disagrees exactly, just not being involved might cause confusion and follow-up questions. It can feel like disagreement, even if it’s just clarification. Some of your work might have to be re-done or started over. People have to feel confident in what’s been done. Not being included does not make people feel comfortable.

True vs. Useful

In this excellent blog post, in the epilogue, the author explains JavaScript’s difference between let and var.

I use var because it works really well, it’s very flexible, and it behaves according to a predictable set of rules (just like the rest of JavaScript). But, var doesn’t always work the way I want it to; and so, in those situations, I will gladly use let in order to get the job done.

https://www.bennadel.com/blog/4185-creating-jquery-function-parity-with-umbrella-js.htm

That bit about “behaves according to a predictable set of rules” stood out to me. It reads like an apology for JavaScript. Is it true that the language “behaves predictable”? Sure, nobody could program in a language that didn’t behave predictable. Even toy programming languages that are annoying for fun, like brainfuck, still behave predictably. That’s not really helpful. It is semantically true, but it isn’t honest.

A more helpful thing to say would be that JavaScript is predictable in the way that a 2yo toddler whose been given a caffeinated drink, sugary candy, and breakable glass tableware is predictable. The fact that the author has to deeply explain let versus var is a sign that the language has far too much going on for it’s own good. I can’t make this point any better than referencing Wat.

WATMAN

https://www.destroyallsoftware.com/talks/wat

I try to keep an eye out for this sort of thing. People say a lot of things that are true, but not useful.