caprock

Off the cuff, I suspect I would feel proud to work in one of two conditions:

A) A place delivering support to those in need, within my geographical community. For example, working for an organization running a food bank, career oriented learning, and similar services.

B) A team working on a cutting edge area of science and/or engineering, which would advance human understanding in a way that will lead to overall societal improvement.

It's possible though, that I'm conflating pride and fulfillment.

Interesting. There must be some internal inconsistencies across accounts (not surprising for something that's existed this long). So maybe they are slowly working through the changes as they hint.

For instance, in the past month I received this notice, unprompted, from amazon:

Greetings from Amazon Web Services,

In the past, you have used the same email address and password to sign in to Amazon.com and AWS. In response to customer feedback, AWS is updating your account to make your access to Amazon.com and AWS independent. You can continue using this email address and your current password to sign in to Amazon.com. However, the next time that you sign in to AWS, you will be prompted to create a new password and will have the option to register a new multi-factor authentication (MFA) device. MFA is a best practice that adds an extra layer of protection on top of your email and password.

Combining htmx, _hyperscript, tailwind, and my preferred server side tech has really minimized the web ui friction for my projects. Good luck with the end run and I hope it works well for you too.

Using a combination of tailwindui, htmx, and a little _hyperscript has gotten me over similar hurdles.

It's really brought the joy, simplicity, and dev speed back to web ui work. Plus it pairs with whatever backend you want.

Hands down, the best and most interesting software projects I've seen were usually created by 1-2 individuals.

Aside from that, maybe the current sqlite team. Also, the twisted python team back in the day.

Here's a place to start...

In your next few sessions of free time, open up a text file or physical notepad, and proceed to just write down all the things you are interested in doing in life. Don't worry much about the structure or how it's done. Be creative. It can be lists, paragraphs, sentences, mixtures, and so on. Make side comments, draw pictures if you're feeling that. Just get it all out in brain dumps over several sessions. Don't limit yourself to "side projects". Include things like exercise, recreation, learning, social desires.

This brain dump will allow you to empty and relax your mind.

Next, begin to think about organizing with an aim toward finding the next 1-3 things that you want to prioritize. How you prioritize is up to you, and very personal. Accept that choosing to prioritize thing 1, will mean deferring things 2, 3, and 100.

Finally, in the next session, switch from organizing to doing. Just do a small task or activity related to the top priority.

Do as many implementation sessions as you like. When you start feeling scattered and anxious, go back and spend some time organizing.

----

The big picture...

As a part of this process, begin to recognize how this organization time is legitimate work. It's the prep work, the executive function time, which you do before you start implementing. It's a never ending loop of organizing and doing.

Additionally, recognize the brain dump and wherever you keep all these notes, is your external reference store. You don't have to walk around with all the ideas and goals in your head now. You can relax and focus on the top few priorities, and return to your written notes as needed.

If you want a more structured variation of this, read and try the Getting Things Done book and techniques.

I can recommend 1-3 hour walks combined with podcasts, especially longform podcasts

If you're interested in the topic of consciousness, and particularly viewing it through a more computational lens, I recommend seeking out some of the interviews with Joscha Bach from the last few years. He's been on several podcasts, which can easily be found on YouTube by searching for his name.

He's clearly been spending a lot of time thinking through the topic. As a result, the interviews make for very engaging listening. Given the conversational nature, he doesn't always get to lay out the ideas in a linear fashion, but that almost seems to make it more interesting. I've gotten a lot of joy from repeat listens and piecing it all together over time

1. Build a functional test system, and write a big suite of tests which ensure preservation of behavior. Make it easy to run and see the results.

2. Slowly start extracting code and making small functions. Document like crazy in the code as you learn. Keep the single file or close to it, and don't worry about frameworks yet.

3. Introduce unit tests with each new function if you can.

After all that is done, make a plan for next steps (framework, practices, replace tech etc).

Along the way, take the jr backend engineer under your wing, explain everything, and ensure they are a strong ally.

Call me crazy, but that project sounds like fun.

A lot of these are interesting:

https://webring.xxiivv.com

Is this also true for Grammarly?

For a nice collection of shorter stories, there's also:

Founders at Work: Stories of Startups' Early Days Book by Jessica Livingston

The Soul of a New Machine by Tracy Kidder

This is a fantastic book about the individuals and team building a machine at Data General around 1979.

That sounds like a reasonable point, from a purist business perspective.

I have a tendency to assume the big players like meta have many pockets of inefficiency with respect to engineering headcount, and that many projects aren't very important (or even negative) to the bottom line. Maybe that's not true.

It still sounds like they are taking a low friction path, and a little more effort here might result in a decision that has better social outcome. There's not enough info to say that with real certainty though.

This sentiment is one I understand, and I'm not fond of deference to power either. That section of the article though, illustrates an example which I would say is useful when challenging any idea, not just one from a person with more "power". It's a small signal that you're going to challenge the ideas, and it gives the other party room to prepare. A social protocol if you will.

There are quite a few good ideas in tfa. The power deference is frustrating, but it's also a reality with groups of humans. In the end, you can build up your own forms of informal power and social capital if you deal with this kind of situation pragmatically. As a result you can become someone people will trust to discuss ideas effectively.

It's a little difficult with this article, to clearly understand the chain of responsibility. Does meta employ the vendor that employs the service staff? If so, who really decided to make staff cuts? And how does the union intersect with this?

Unrelated, there are approximately 200 service people cut, making approximately $20/hr. That's roughly $8M a year. Certainly that's a lot of money, but I wonder why meta would choose to cut this cost and not some other. For example, why not lay off 20 engineers? Or is this related to fewer people being in the offices now, so there's literally less work?

It seems like a compassionate capitalism approach, wherein there's a bit more preference for preserving the jobs for the lower economic class would be worth considering here.

One idea:

Try starting with an alt on twitter, which gives you some freedom to experiment and make mistakes.

You might also enjoy this article:

https://www.ribbonfarm.com/2020/01/23/being-your-selves-iden...

It's ok to be happy.

Yes, it's worth it, for multiple reasons.

There's already lots of good advice here. Here's a variant idea:

Take a two week vacation from employment very soon. Spend the first week doing nearly nothing aside from your version of recreation. Spend the second week thinking about whether your current pattern really brings you fulfillment, and along with that, make the plan for your mini-break (resignation plan, negotiate for unpaid time off, etc).

> Distributing requests to GPUs with the best available price on the global market dramatically reduces cost

Can you provide more insight into how this is accomplished? I remember seeing a similar sounding gpu rental service, but the name escapes me. Is this distributed over end user GPUs volunteering their devices, or just spot style cloud instances?

Oh, great point. That's a fantastic book.

I was throwing it in as a bit of humor, but your comment illustrates how it really can provide fuel for an interesting set of conversations around ladders/roles where an engineering team can thrive.

Does the peter principle assume a person stops learning? On the surface, yes. And if learning leads to skills, maybe we could also consider success in different jobs as a combination of both skill and motivation. This would highlight a couple of the common, real-world problems I see when engineers "rise" up the ladder:

1. A first problem is many senior roles require new organization and leadership abilities, thus the core of the Peter Principle. (skill)

2. The second is that absent careful thinking and goals, many engineers will seek arbitrary advancement only to find their ability to succeed disappearing when those new skills aren't as fun/engaging/fulfilling. (motivation)

I'm curious. Were there many newspaper and magazine articles about life at IBM, GE, and other large corporations in the the 1950-1980 time frame? Did this trend of corporate culture commentary arise with periodicals like Byte, Dr. Dobb's, and Wired Magazine? Before?

Unfortunately, what I see the most is:

An increase in seniority comes with (A) a decrease in hands-on time with technical problems and (B) an increase in time spent on project management, team organization, and people problems.

None the less, there are some possibly interesting resources regarding levels at Honeycomb [1], Netflix [2], and Gitlab [3]. There's a whole book if you're going to venture into "staff" [4]. Last but not least, don't forget the Peter Principle [5].

[1] https://www.honeycomb.io/blog/engineering-levels-at-honeycom...

[2] https://blog.pragmaticengineer.com/netflix-levels/

[3] https://about.gitlab.com/job-families/engineering/developmen...

[4] https://staffeng.com/guides/staff-archetypes

[5] https://en.wikipedia.org/wiki/Peter_principle

> We show that NN loss landscapes contain effectively only a single basin(!) provided sufficient width. Even better, we develop practical algos to navigate these basins...

Supporting twitter thread:

https://twitter.com/SamuelAinsworth/status/15697194946455265...

Paper:

https://arxiv.org/abs/2209.04836

Thanks for all the answers and insight!

This is pretty neat! It's great to see relatively recent advancements in machine learning, put to use for child education.

A few questions for @Cherian:

1. I see the ASR usage, but where does computer vision come into play?

2. Are you training and/or fine tuning asr models to deal with the speech characteristics of children and new speakers?

3. Is the asr all cloud side, or do you have it running locally in some fashion?

There's something quietly pleasing about this settlement. It's as if Mudge is still hacking away, but this time it's an inefficient corporate machine. Good for him.

This quote from his wife (sourced from wikipedia and in turn from Time), is quite pointed:

Remarking about her husband’s time at Twitter in an article in Time Magazine, she said, "dishonesty is definitely something that frustrates him."

This is a great story and interesting set of observations. Thanks for taking the time to share!

Sure! Admittedly I was being a bit casual with the distinction.

With a little time and experience maybe one could develop a set of heuristics. Or maybe site selection would just be case by case.

Curation is a long standing challenge, and perhaps growing in importance given the recent influx of advancements in generative technology.