caprock

Maybe this is a sign to try something different with your time.

Add more diverse characters which overlap with the personas you're seeking to appeal to?

I'm not sure there aren't already highly educated viewers. I'd also point out that not all highly educated people are the same.

In the end I find most wrestling enthusiasm stems from childhood viewing with friends or family.

In current times though, it also has to compete with the adjacent mixed martial arts.

Try cursor and 3.5 sonnet. It's definitely good enough. It's good if you give it specific functions to write or if you write a well structured plan in markdown.

You'll be fine, especially since you are making a best effort to adhere to the rules. While many people like to nitpick the specs of the contract, and they aren't technically wrong, the reality is nothing happens from the corp side without them having significant motivation and willingness to spend the time, effort, and money. There's extremely low probability of them taking any action (or even knowing about it). Plus California laws are fairly labor biased.

For a start:

There's a nice indie hacking and build in public type community on X. You can find lots of people there and see what they are doing in terms of posting.

Next, just look for communities where your potential customers hang out. Participate sincerely in their communities and offer your service when it's appropriate.

Mostly just have fun, participate in other threads, and generally be active.

This is pretty interesting:

The Architecture of Open Source Applications https://aosabook.org/en/

What's interesting to me is how this is also true for interactions with other humans.

I wouldn't say human code will be a hazard. More that Humans augmented with AI will be able to deliver more quickly, which is a potential business advantage.

Humans guiding AI via a well integrated tool like cursor are reporting lots of successful outcomes but it's a bit of a new process still being learned.

It's very clear that more computation (and ram) on larger models will produce better results when talking about general model use. This will be true for a while.

Eventually the marginal benefits might plateau in combination with enough optimizations to make local use outweigh any cloud models.

More specific and narrow use cases are a different matter.

Whether applied to vibe coding or other tasks, I think it's the iteration and interaction that is the hook. And I do think it could be leveraged to practice and improve reading and writing.

ctrl-r in bash tops my list, even if it's not quite what you are thinking of as a unix tool.

Probably the pipe itself would be my favorite next.

Then in no particular order: tail, cut, xargs, wc, tr, grep, sort, uniq.

I'll suggest some, all very different.

1. The Software Developer's Career Handbook: A Guide to Navigating the Unpredictable by Michael Lopp

This is about all the things around being a programmer at work.

2. The Soul of a New Machine by Tracy Kidder

This is a well regarded book about an engineering team building a Data General computer in the late 70s. So the lessons are indirect, but it's a pleasant and technical read. It reads almost like a novel.

Separately, I think it's worth reading at least a couple things that are more cynical. It's helpful for balance. On that front I'd say...

1. The Gervais Principle by Venkatesh Rao

This is a lengthy blog series (or ebook). It uses a metaphor about The Office, but it's still plenty relatable if you didn't watch that show. The abstraction this lays over modern knowledge work is quite interesting. It's a weird combination of demoralizing and liberating.

2. The Peter Principle by Peter and Hull

I remember reading this book and having trouble understanding if it was real or some form of satire. If I read it again now, many years later, I'd probably understand it better.

I'd say the most valuable skills are ability to learn / adapt, attention to detail, curiosity, and resilience.

It seems like you're doing things right. Just keep iterating, learn from experiments, and do it again. Sure, you might be over-simplifying some things, but you'll figure those things out with each experiment. Go with your energy and keep iterating.

A good first step is to imagine something fun you would like to create for yourself (or whatever idea you already have), and then try building that thing as a side project. Limit the experiment to no more than 3 months. Learn how to heavily reduce the scope and build almost every day. See what you learn about yourself and then regroup.

Why do I suggest this? Many reasons. Here are a few:

First, you'll learn that the biggest hurdles to success are your own mind and habits. To even have a chance, you need to learn how to motivate yourself and work without a lot of structure surrounding a project. This is really useful.

Also, regardless of what kind of product, and regardless of whether you want to start a VC backed or bootstrapped company, the first step is getting started and showing some sort of traction. Again, keep the time limited, or you'll waste a lot of time building something no one actually wants. This part is when you'll start to learn about the all important product-market fit.

Finally, you'll learn about what happens when you have something besides your normal work to care about. This is an interesting dynamic. It might change how you feel about work, or it might not.

As far as the concern about stagnation, I've found that rarely goes away if you still have ambition about employment. Once you have a family, this only intensifies. Your personal tolerance for risk might change this dynamic. If you do enough interesting tech stuff on your side project and/or startup, then you can satisfy some of that concern.

I've seen similar things happen. This is a great example of the unintended second order effects of regulation. Good intentions don't ensure good outcomes.

It's ok to be confused, and dealing with this kind of ambiguity is a normal part of life. I'll provide some ideas, but the real moves are always up to you.

First, it sounds like you're not being challenged anymore or able to really apply your skills to the fullest, thus the depression and looking outward for change. You have the right idea to look for change.

More specifically, look at as many jobs postings as you can for a few weeks and get a feel for what is in demand. Select a few that sound like fun. Then work backwards and make a plan to build the skills described in the postings. You can do that with personal projects, open source contributions, or side work.

As far as suggestions, I see two fairly straightforward options. First, as you mentioned, you could try a new language. Personally I'd suggest Rust as it's more interesting, closer to C++, and used in a broader array of domains. But golang is quite common and has some fun aspects. You'll get a feel for the domains as you scour all those job postings (try reading all the whoishiring posts).

Second, you might also consider looking for a more senior role with C++ where you are building something new. Maybe the maintenance and bug fixing is the problem, and you just need to work on the early part of a project where you have greater responsibility for creating and design. A startup will often take a chance on someone with less experience, so don't underestimate your qualifications.

Again, what you're experiencing is normal, so try not to let it get you down. Keep scouting for new and interesting opportunities. The market is kind of slow right now, so it's a good time for working on those those side projects to build experience while you keep searching and applying. You'll be ok.

What's the work you're pursuing?

Affirmative :)

I miss the prevalence of telnet and finger. There are still plenty of telnet accessible services, but not as commonly as before.

It would be fun to read a detailed writeup for just one successful infiltration. All the small details, step by step.

Anyone have any movie recommendations for a more modern version of Sneakers (great movie)?

The Gorilla Sun newsletter is a cool resource. Here's a recent edition:

https://www.gorillasun.de/blog/gorilla-newsletter-71/

Difficult to learn indeed. Generally, employment gets a lot of interaction time each work day, and it's hard to set boundaries against that volume of input. I'd love to hear how people have learned to do that.

From your perspective: What are the characteristics of a healthy career? Is it healthy to have a plateau where you sustain some level (say Sr SWE) and don't "advance"?

That is indeed wild. Did you confirm it's 24 month term?

I read (but didn't confirm), that it's on a payment plan. So maybe it's more like renting the domain, which makes at least this detail sound more reasonable.

ZeroMQ - https://zeromq.org/

From my understanding, the protocols for each of these systems are inherently coupled to the internal service characteristics. RabbitMQ and Kafka take very different approaches to messaging. Neither is generally better, and they each make different tradeoffs.

These tradeoffs have real impact on client logic. And in this case, where it's not as simple as a line protocol like http, it may be hard to disentangle the "objects" and the protocols.

With that in mind, I'd choose the one which is most similar to your internal messaging service so there's less impedance mismatch.

Very interesting. Could you provide an example of this being applied?

From what I've seen, there are sort of two paths if you're running on your own hardware or VMs. I'll provide a well known example from each.

1. lang specific distributed task library

For example, in Python, celery is a pretty popular task system. If you (the dev) are the one doing all the code and running the workflows, it might work well for you. You build the core code and functions, and it handles the processing and resource stuff with a little config.

* https://github.com/celery/celery

Or lower level:

* https://github.com/dask/dask

2. DAG Workflow systems

There are also whole systems for what you're describing. They've gotten especially popular in the ML ops and data engineering world. A common one is AirFlow:

* https://github.com/apache/airflow

The resources for "From Nand to Tetris" are commonly recommended for scenarios like this. Enjoy!

* https://www.nand2tetris.org/