A small post just to break the blog hiatus. Once upon a time there was a Prolog interpreter that was used in the Windows NT kernel. You can read about it here. The code is in the public domain and years ago I had downloaded from the net. It seems that it took me close to 8 years to put it on GitHub, for software archaeologists to dig into if they like.
Today it was my fourth (I believe) encounter with APL:
- First, too many years ago when skimming through Tim Budd’s “The Kamin Interpreters in C++” (and the Kamin book afterwards). For the hardcore fans, Tim Budd has a book on implementing an APL compiler.
- Next was a Dr Dobbs issue about the J programming language.
- Some years a ago a comment on this blog about Dyalog.
[ Mostly saving this post for posterity ]
I had heard of the language long before it was made Open Source. In order to get access to the implementation I had Timos Sellis sign an NDA with Ericsson. I had fun with Mnesia (the distributed DBMS) and started thinking of whether it could be applied to stuff I was good at at the time (namely SMTP and DNS). In fact it was. Because most of the Erlang team formed a company named Bluetail that was making software based load balancers with Erlang and got sold at $152M.
Nowadays I occasionally have “fun” with the Erlang VM whenever I have a RabbitMQ instance go mad.
But this? This is something only someone like the guy who writes RabbitMQ could discover:
I found out about the Expert Beginner book from Avdi Grimm’s newsletter. It is a small but discomforting book (a series of blog posts turned into a book) that I believe anyone in programming, systems administration or DevOps arena must devote some hours to read. Its basic premise is the following extension of the Dreyfus model:
While the book is a guide on how to spot and avoid Expert Beginners (people who believe they have mastered all there is to master in their field and anything beyond what they already know is useless), it also serves as a guide to spot when you start emitting Expert Beginner signals yourself.
Do yourself a favor and read the book. Especially if you consider yourself a guru, ninja or rockstar of something. It will only cost you two hours.
I got You are a writer by Jeff Goins on a day it was given for free years ago. I got to read it over the weekend. I thought then, and I still do no now, that the book offers advice to people who write code too. Maybe because sometimes I believe that code is like a poem. So I will try to rehash advice I found useful here, since this seems to be one of the acceptable self-help books that have come my way.
While anyone can connect with anyone and put stuff out there, how does one gets noticed? By helping people. By relieving their pain. I’ve advocated answering one question per day on ServerFault (or StackOverflow, or whatever clicks to you), although I do not always practice this. I used to, though, years ago when mailing lists and newsgroups were the thing.
You need to build a platform. This blog is a platform. I post stuff here. Others do it with more success, for example John Sonmez who uses a variety of platforms (blog, YouTube channel, podcast, book) to publish his work (and he gives 90% of his work for free he said on Ruby Rogues). You make the platform and you establish a brand. Without a brand you are forgettable.
And you know what helps you not being forgotten? Networking does. Meaningful relationships do. Relationships that are mutual, matter to both parties and give you the opportunity to make friends and find mentors.
But nothing of the above makes any sense unless you are prepared to answer the following questions:
- Am I serious?
- Am I committed?
- Am I prepared to be challenged?
Please take the time to sincerely answer these questions. And while you are at it, understand that you probably are not the best coder in the world yet. But you can become one. There is room at the top here.
Like one of the main characters in The Phoenix Project said, mastery comes through practice. And here Goins argues that the best kind of practice is done publicly. Interestingly GiHub seems to be our public place of practice.
While you’re at it, learn to estimate. Underpromise and overdeliver. Especially when you are part of a team. Like Goins writes, you have a gift. Someone is willing to work with you.
Go on! Practice.