Digital Man's Web Log

And by “FidoNet”, I'm not referring to the message network itself but rather the underlying technology (aka FTN).

Before you can “fix” something or just replace it with something better, you really should have a comprehensive, enumerated list of what's wrong with the existing “solution”.

This list is of course, just my opinion, but it is an informed one with about 30 years of experience with FTN from both a user/sysop's perspective and a developer.

Likely the biggest problem with FTN is that much of the software that is used to run the network is abandonware with no hope of being upgraded to support any substantial improvements in the underlying network technology. Most substantial improvements to the network technology would leave a lot of existing nodes behind and hamper the possibility of retro-systems being able to join and participate in FidoNet. The requirement of strict backward compatibility with software written in the 1980s and 1990s is the pervasive rationale of the FidoNet network members for not accepting proposed solutions to the network technology's shortcomings.

The one saving grace has been extensibility via the message “control paragraph” (aka “kludge line”). Since it was specified early on that message lines beginning with a Ctrl-A (ASCII 1) character must not be displayed, as they contain “control information”, this has been the scheme by which additional or improved message header fields have been added over the years. Unrecognized control lines are ignored by receiving software and thus backward compatibility can be maintained while still defining and using new control lines in messages created and consumed by newer FTN software.

The geographic location of the FidoNet node (continent, region) is encoded in the node address. While this is true of IP addresses as well, the Internet has a handy solution called the DNS. While I do like that it's obvious to an experienced BBSer that it's a FidoNet address when you see one (e.g. “1:103/705.1”), it's certainly non-intuitive what all the symbols and numbers mean and is not easy to remember. An addressing system that uses human-readable (and memorizable) “words” for the addresses of the network nodes would be much preferred.

The so-called “type-2” or “stone age” FidoNet Packet format was originally specified and accepted as the FidoNet standard method of message exchange in 1987 and hasn't really progressed much since then. Although there were a few proposed packet format replacements twenty-plus years ago, none of them were accepted as a standard. There have been some incremental improvements to the type-2 packet definition (FSCs 39, 45, and 48) and while FSC-48 (“Type-2+”) has long been the majority-preferred packet format, none of these improvements has been ratified as a formal standard.

The problems with the Type-2 packet format and its derivatives (and their “packed message” format) are:

1. Lack of extensibility (no real way to substantially add more header fields or extend the length/range of any already-defined header fields)
2. US-ASCII only text field with no support for using Unicode or other character sets
3. DateTime header field that is plain text, represents local time, with a 2-digit year
4. Artificially limited string lengths (i.e. 35 characters names, 71 character subjects, 8 character passwords)
5. Relying on NUL-terminated (ASCIIZ) strings (most of the time)
6. Little-endian integers (x86 architecture assumed at the time)
7. Reliance on echomail “origin line” for the originating address

Prior to and during the time that FidoNet technology was being originally defined and implemented, there were parallel peer-reviewed developments with similar Internet technologies (e.g. SMTP, NNTP), and yet, FidoNet standards don't reflect any of the learnings or best practices from these open Internet standards or RFCs. This blindness to more robust existing open solutions to the same or similar problems is pervasive throughout the history of FTN, but is particularly and painfully obvious in FTN Message-IDs.

While there have been enhancements to support non-US/English character sets (code pages) and even UTF-8, they're awkward (e.g. you have to parse a message's text to find a CHRS control paragraph before parsing/displaying the header fields correctly?) and not universally supported. Anything other than US-ASCII in message headers or text is clearly an afterthought and mostly does not work as a user would hope.

Any system that requires extensive manual maintenance is bound to be wrong more than it is right and I think the FidoNet node list is an exemplary case. I have not used a node list on my FidoNet-connected BBS in more than 25 years and I don't miss it. The format, purpose, and use of the node list is all highly suspect and begs to be replaced by something more distributed and automated.

In the title, “Why BBS?”, I'm using “BBS” as a verb, as in “Don't anybody pick up the phone, I'm BBSing!” Or in other words: Why should anyone do anything with BBSes today?

Of course, the plural noun “BBSes” I'm referring to here are the arcane systems you can run (as a sysop) or connect to (as a user) today which emulate or replicate the old dial-up bulletin board systems of the late 1970's through the 1990's. These BBS connections are typically over the Internet using terminal protocols like Telnet or SSH, but may also include traditional dial-up modem connections over the “plain-old telephone service” or even over amateur-licensed radio frequencies. But since you're here reading this, you probably already knew that.

BBS users or sysops that are either new to the scene or returning after a long absence often offer their observations about the state of BBSing and their recommendations to restore or at least increase the popularity of BBSes beyond the niche they serve today. But not everyone has the same intentions or goals when it comes to this hobby, so while some may think relatively low usership or participation indicates something is wrong, others might not see that as a problem. If you want content consumption or participation from thousands of daily users, maybe a BBS isn't the right thing for you. There are certainly plenty of other interactive platforms and technologies that may be more accessible or attractive to your target audience or user group.

I'm not trying to talk you out of using or running a BBS; I just think you should have realistic expectations. If *you* like using or running a BBS, that should be all that matters. You can't force that enjoyment or desire on others. If you can't find the content or participation level you'd like to see in BBSes, that doesn't necessarily mean there's something wrong with BBSes.

If the BBS users and sysops of the 1980's and 90's were asked to describe their dream online system of the future, they probably would describe something similar to the AOL/CompuServe/Prodigy online services of early 90's or, if they were true visionaries, the modern social media Internet services of today, e.g. Facebook, Twitter, Reddit, YouTube, etc. I doubt very much they would envision a modal 80 x 25 ANSI terminal interface as the ideal online user experience of the future! Facebook and the like are kind of the natural evolution of the large-scale BBS and they will continue to evolve and look and feel less and less like the BBSes we knew “back in the day”.

As for myself, I still endeavor to improve the content availability and user experience of today's BBSes, but I'm under no delusion that any BBS is about to supplant the behemoth social media services that have been and continue to be created and cultivated by mega-corporations.

However, that doesn't mean that BBSes can't remain fascinating and captivating to those who are inclined to be fascinated and captivated by them. *My* first fascination with BBSes was because they were obscure and arcane: very few people at the time were online and here was this secret world I had discovered. I had similar discoveries later with MUDs, IRC, CU-SeeMe and amateur radio. I'm attracted to these obscure hobbies and enjoy the comradery I find in others with the same interests.

Today, my interest with BBSes is more in the technical challenge of marrying old technologies with new and creating bug-free software while also trying to inspire BBS content creators and participation among the BBS users we do have. I don't necessarily think we need more BBSes or even more BBS users: if all of today's BBS users just used one BBS, that'd probably provide the BBS experience that a lot of users would enjoy/expect more than the hundreds of tiny islands we have. But having more BBSes provides more technical challenges for me to solve: more platforms to support, more variance in sysop-customization and configuration and BBS inter-networking use-cases. And most of us really do like the idea of having their own island to decorate and dominate as they see fit; so I focus on inter-connecting hundreds of tiny islands as seamlessly as possible with an engaging user experience. And that's fun for me!

So that brings me back to the question: “Why BBS?” and here are the answers I have to offer you:

1. Nostalgia:
   you likely BBSed back in your younger years and its one of the ways we can still feel young
2. Obscurity:
   it's highly unlikely your ex or your next prospective employer is going to find and judge your BBS activity
3. Independence:
   the content, management and durability of your BBS is really up to you (it's your island)
4. Challenge:
   the technical challenges involved should be fun and give you a sense of wonder and accomplishment
5. Creativity:
   within the limited confines of BBSes, there's still plenty of room for the astonishment and inspiration of others
6. Experience:
   believe it or not, knowing how BBSes work may give you a step ahead in your future technical aspirations
7. Community:
   there is a BBS community, or several, and they will likely welcome your participation and enthusiasm for the hobby

So in summary, I agree: BBSes can be made more accessible and user-friendly than they are today and support more mainstream use-cases than they do today. And maybe, probably, some of those enhancements will come to fruition in the near future. Perhaps your contributions will help drive the innovation you seek. But in the meantime, see if you can find the enjoyment and inspiration that we've found in the BBSes of today and rejoice in that!

Things I Learned Interviewing for Programming Jobs in 2019 - advice to myself or those living in similar shoes

1. Buy and read “Cracking the Coding Interview”, multiple times. It’s your new bible.

2. If C is your primary programming language, learn/choose a higher-level language (e.g. Python, JavaScript, Java, C#, even C++) that you can use for the academic/CS/algorithmic questions, if you get asked them. C is often not your best choice for those types of questions.

3. Even though you may never use those academic/CS skills (big-O, data structures, algorithms) in your actual job, if it helps you to pass the interviews (and it often will), they’re worth learning.

4. Use the free web resources for learning academic/CS skills and practicing them in an interview context. http://hackerrank.com and http://pramp.com are two of my favorites, but there are many more like them. Sign-up for and participate in free/visitor coding bootcamp sessions (e.g. outco, interview kickstart).

5. “Reverse a linked-list” is the new “fizz buzz” question. Counting the number of set bits in an integer (or determining if it’s a power-of-2) is a close second. Flood-fill (and similar recursion) problems are also popular. If you can’t solve these problems, you’ll look bad. Practice these.

6. Memorize the time and space complexity (big-O notation) of most common data structure operations and sorting algorithms.

7. If you’re asked to write code on a whiteboard but blank-out on what to write, start by writing keywords from the problem description, or the entire problem description, draw example test cases (input and expected output), draw pictures – anything. Don’t just stand there staring at a blank whiteboard wondering how you’re going to pay your rent because you suck.

8. Dynamic programming and recursion should not be the first solution you reach for to solve *most* problems, but don’t forget that you have them at your disposal. I saw a few Pramp (mock interview) partners solve relatively simple problems in absurdly complex ways because they (too) quickly determined that dynamic programming was the only or ideal solution when it was not.

9. If the solution to the interview problem seems easy/obvious, it’s probably because the interviewer is hoping you’ll dive deeper and find a more optimal solution than the obvious or brute-force solution. But not always; sometimes it’s just a prep question and the “real” (more challenging) question is coming next. Listen carefully to the interviewer for clues.

10. If you get asked to complete a “take-home” test, use all available resources to test/verify the code before submitting it (e.g. gcc -Wall, lint, coverity, valgrind, etc.). Beautify the code (e.g. with uncrustify or clang-format) before submitting it. Double and triple-check all the requirements and test cases. The code should be as clean and as perfect as you can make it.

11. The more senior/experienced you are, the higher your compensation level, the longer it’ll take you to find your next job.

• It can take several months for the critical mass of interested and able companies and offers to come to fruition. Don’t give up. Don’t stop preparing. Stay the course. Don’t get discouraged.
• There are 10 times the number of available positions for experienced/senior developers in the Silicon Valley / Bay Area of California than other areas of California, even L.A., O.C. and San Diego. The Seattle and Redmond areas of Washington state are second best.
• Remember that no single engineer/programmer knows everything. Everyone has strengths and weaknesses (gaps) in their knowledge and experience. You are good enough. Your personal “scalability” (ability to learn/adapt quickly) is your primary merit. It may just take a bit of luck to get the right set of interviewers/questions to prove this to the right employer at the right time.

12. Apply “direct” first, then cast a wide net:

• Begin by applying directly to all the corporate sites of the companies you think could use your skills and whom you think you’d like to work for (old competitors, big name companies you admire, etc.). You’ll come to hate “myworkday” web forms, but just do it. Every. Day. Don’t bother with the custom cover letters or supplying personal references initially, unless they’re required. Know that many corporate job postings are fake, especially from the big corporations that are sponsoring immigrant-visas. These fake postings will not be on their corporate web-site, however.
• Next, search and apply to all the relevant positions on LinkedIn, Indeed, and Hired. Every. Day. Apply to http://triplebyte.com. Don’t bother with dice and monster.com unless you want to get spammed with completely irrelevant job ads.
• Let your friends and old co-workers know that you’re looking for your next opportunity, you never know who knows who and where those leads may go. Use your contacts!
• Reply to any old emails from company recruiters, even from years ago. That recruiter likely doesn’t work there any longer, but your email may go to their replacement or supervisor and get you an interview quicker than an online job-board application.
• Go ahead and sign up with all the headhunters (CyberCoders, etc.). Can’t hurt. But don’t feel committed to any single recruiter or agency – they’re not committed to you.
• Aim high in both the companies and the positions you’re applying for.

13. Before any interview (phone or in person):

• Scrutinize the job description/posting. Any tool/language/protocol/tech mentioned that you haven’t already mastered, research it and prepare. Even just reading relevant Wikipedia articles may give you all the background you need to satisfy the interviewer.
• Study every page of the company’s web-site, learning all about their products or services, leadership, location, job board, etc. You may be surprised what you learn and you’ll be better prepared to talk about their problems and your solutions to them.
• If you have a list of interviewers, consider looking them up on LinkedIn, GitHub or other social media and from that information (FOSS projects, previous companies, job descriptions, education), better prepare for your interviews. But know that LinkedIn Premium subscribers can be notified *who* viewed their profile, so you do risk the interviewer knowing that you were researching them. If you choose to research them, don’t tell them that you did – it’ll sound creepy (and no, they won’t be flattered).

14. During interviews, pay close attention to the questions asked and the words used. These words are valuable clues as to what the next interviewer may ask you. Take notes (mental or physical) and research any weaknesses that have come to light between interviews. Learn from each interviewer how you can better answer questions from your next, even for the same job, on the same day!

I hope these tips may help you in landing your next “awesome coder job” at the company of your choice.