clavalle

Slightly lower than one of MIT's alumni doing the same.

It's telling that Jane Street stayed away from the whole mess despite the connection.

Counter proposal: I'll learn to relax

'Cannot' being the operative word.

'Did not' does not necessarily mean 'cannot'.

Writing simply helps me to think clearly. So journaling is just a way for me to crystalize my thoughts. And it works great for that. It also helps me see patterns I might not be aware of over time.

Mine tends to be stream of consciousness, just one level above brain-dumping on scratchpaper, until I hit on something I want to explore. Then it becomes more structured (and sometimes ends up very structured indeed in mindmaps or various project folders, etc).

It works great for me. I get ideas down in useful forms. I don't have to continually consciously think on ideas to keep them alive, reducing cognitive load. I have a tool for effective reflection. I feel like it's helped me lead a more intentional life. Simple as that.

Not only that, software is a unique sector in which a lot of the capital is in the talent.

These companies aren't laying off labor that have few choices. They're budding off knowlegible competetors.

If these folks can't find a well paying job it's a very real option to create a well-performing company.

Nothing is more expensive than cheap talent.

Besides, the market is still super tight and shows very few signs of loosening.

What we're seeing is that the old-guard companies have hit their autumn years. But companies being companies autumn could last for decades.

I think we had too much talent dedicated to some of these sectors anyway. There's a lot of interesting problems out there that could use more attention.

I have personally been approached by internal recruiters for a position just after the company very publicly laid off people with my title and are going after 'middle management'.

I declined.

I'm a software architect but I strongly believe that the organization of people is as important as the organization of software. So architects and principals, to be the most effective, should have management authority. Middle management, if done well, makes or breaks mid to large software companies. An organization that doesn't deeply respect that role isn't anywhere I want to be.

Are there any journalism democratization efforts we should be aware of?

An organization who has incentives aligned with providing journalism for the people?

>"Don't get me started on having to fill out sections in a form that are just resume sections"

I haven't been laid off but I've been dipping my toe in the past few months because I'm a bit bored in my current role.

The process is much more fiddly than it needs to be. When I run into those 'fill this out again for our system' forms, often times it's after a long day and I will just save it to come back to it later...and I never do.

I wonder how much talent mobility there'd be if someone really solved the issues of repetative job search data entry and just proving to strangers that you can excel in a role without running through an obstacle course that may or may not represent the actual job.

If they weren't here, we wouldn't be able to talk about it.

I'd be interested to know if we're in an element rich vein of the wider universe or if all the good stuff is more or less evenly distributed?

Right. And the tech unemployment rate still went down despite layoffs up to November's doorstep. There's no data on November, yet. Will be interesting if November arrests that downward trend at all.

- First thing in the morning, standups followed by coaching sessions (basically pair programming or code review) for sticky problems

Then it varies.

- 1:1s

- project or program (in the sense of both code type programs and long term direction programs) planning or status meetings with various stakeholders, especially POs, PMs, and execs

- digging into particularly difficult or odd code or set up issue that's lead to it being escalated

- meetings with vendors and doing a write up of their product's potential and costs

- creating rough project or program outlines with rough budget estimates for execs

- creating design documents on projects or programs that have a bit of traction

- meeting with other architects to collaborate on wider designs or just share items of interest

- going on HN to tell strangers about my day-to-day life

- create fully functional POCs or reference implementations

- doing post-mortems

- examining code from a potential acquisition or quizzing their engineers

- getting on meetings with clients or potential clients to give them a warm fuzzy that a tech person with an impressive sounding title is listening to show we're taking something Very Sersiously and find them to be Very Important.

- regular Open Office Hours for anyone in the company to drop by and chat about anything (lots of good stuff comes from these -- highly recommend)

- fielding various requests and questions from Security and Ops other teams and whatnot.

- Having What-If meetings with sales or execs (danger! There be dragons here! But, with Sales especially, a really good way to figure out what customers are clamoring for)

- Preparing talks and technical outreach

- Exploring New Shiny Things (though I tend to do this more on off-hours just because there are fewer interruptions and urgencies).

In terms of microservices in particular, I tend to ask a lot of questions about data and work flow, how someone has defined a domain or domains, making sure they're not falling into the myriad anti-patterns, making sure what they're doing is going to be visible, tractable, and play nice with the rest of our services including following our common patterns and idioms (and when I run into idioms that they might not know about I document them and make them easy to find) and not create any unpleasant surprises down the road, and that they have given appropriate thought to evolution of the service and forward and backward compatibility during that process.

Martin Fowler is by far my most influential resource on microservice architectures and doing domain driven design well. But I would strongly suggest literally reading everything you can find on the subject. Mostly because it's many subjects in a trenchcoat. Seeing it all from a few different angles will better arm you for whatever comes your way.

Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts by Annie Duke

and

How to Measure Anything: Finding the Value of Intangibles in Business by Douglas W. Hubbard

Really changed the way I approach decision making.

With all of the options these days, I'd wonder about the characterization of 'intrensic'.

Just like when you step out of the ocean in wet trunks you reduce ocean levels.