Back in 2014 I decided that a blog that almost no one reads wasn’t good enough, so I created a blog that no one reads, my computer programming blog, The Hard-Core Coder. (I was afraid the term “hard-core” would attract all sorts of the wrong attention, but apparently those fears were for naught. No one has ever even noticed, let alone commented. Yay?)
In the seven years since, I’ve only published 83 posts, so the lack of traffic or followers isn’t too surprising. (Lately I’ve been trying to devote more time to it.) There is also that the topic matter is usually fairly arcane.
But not always. For instance, today’s post about Unicode.
I don’t know if it’s having been in the saddle so long, having all this retirement time, or the magic of 
November shouldn’t pass with just 
If nothing else (and I think there is plenty of else), I can look back on all those years of writing code and pick out the main themes and principles, the things that seemed to matter most.
Here’s a simple tip! I can’t begin to count how many potential code bugs this has eliminated. It takes some getting used to but once you make it automatic it’s a real help in keeping code and your thinking correct.
Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.
It’s been said that programming is an exercise in managing complexity, and while that’s true, it’s only part of the picture. (Still, it’s a pretty big part!) More to the point, managing complexity applies to much more than software design. A defining characteristic of modern life is its complexity, so learning to manage it might be a Pretty Good Idea!
Time to start talking more about programming. It’s one of my defining aspects. I’ll try to make it as interesting as possible for the non-programmers. For the programmers, I’m sorry, but that means sometimes I’ll have to get a little basic or skirt a few corners. Feel free to use the Comments section!
Physically software is just a long string of numbers. In fact, it’s really just a string of things and not things. Holes in paper; or not holes in paper. Magnetic domains magnetized; or not. Tiny electronic switches turned on; or not. You can represent software as a string of black and white jellybeans. It’s all the exact same thing. What matters is the pattern of thing and not thing.
Now the packages of eight bits, the bytes, are clumped into small groups, usually, of four (4 x 8 = 32). These are called words. In some cases, the words are of two bytes (2 x 8 = 16) or eight bytes (8 x 8 = 64). The phrases “32-bit” and “64-bit” refer to this is the level of abstraction. The software is a string of words now rather than just a string of bits. The words are meaningful in the (abstract) language of the program.
Other professions deal more with abstraction. Architects and Mechanical Engineers, for example, deal with drawings and models, which are abstractions of buildings or machines. They start from a pure abstraction, the idea and design, and work to build a concrete thing. [In passing, computer models and 3D printers have made the abstractions much more concrete. We’ve come a long way since faded blueprints.]
Mathematicians and theoretical physicists are entirely in the realm of abstraction! In some cases, 11-dimensional objects for example, a concrete object is not possible. Or took place long ago; the Big Bang took place a very long time ago! In other cases, the forces, energies or times involved are far beyond our technology. They could be concrete in theory, but we’re not likely to pull it off any time soon.
I don’t like the term Software Engineer. Real engineers have licenses and certifications and prescribed educations. No such exists (currently) for software makers. It is still a new craft in our society (it goes back only to the 1950s or so), and we haven’t caught up to how complex and demanding it really is. Anyone can use the term Software Engineer, so it doesn’t have the meaning it could.
People who work with software are sometimes called knowledge workers, but I think that’s also poor terminology. All workers use their own knowledge as well as the business’s knowledge. Some professions require more base knowledge than others, but it is still a continuum. I just think it’s a vague way to specify a profession.
Logos con carne 