Synchronet v3.18b-Win32 (install) has been released (Sept-2020).

Synchronet v3.19a, now under development, requires libarchive-dev to build successfully.

You can donate to the Synchronet project using PayPal.

Digital Man's blog

Why BBS?

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!

Interviewing in 2019

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. and 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 Don’t bother with dice and 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. :-)

In Other Languages
Translations of this page: