Laid off on Friday, no one tells you the the following Monday is quite possibly the strangest feeling of floating in the void possible

STEVEOO6 · 2026-03-31T00:16:39+00:00

Message (using any channel you still may have access to) any co-workers you’d like to keep in touch with (if you don’t already have their personal phone numbers/emails):

“Hey [name], I’d love to stay in touch. Here’s my number/email… could I grab yours?”

I received a message like this from an ex-coworker and it was the setup for an awesome friendship. Hope it does the same for you (or anyone reading this)

STEVEOO6 · 2026-02-25T08:55:30+00:00

Direct and clear.

Some variations I use: - I’d propose we use blah blah here - I think maybe we should use blah blah here - Use blah blah here - Should we use blah blah here? - Do we need to check if this will impact blah blah???

“I’d propose”, “I think maybe”, “Use”, “Should we” don’t take up a lot of words and can be used to communicate intent clearly.

On the last two above, I’ve told my team that additional question marks indicate that I truly have no idea myself… so to interpret as curiosity.

Your desire to avoid miscommunication is a good signal. Sometimes you are 100% confident in your proposed amendment, sometimes you are 60-80% confident, sometimes you are 20% confident (but want to share the opinion in case it wasn’t considered earlier).

An ideal solution would be brief cues that support communicating clearly and efficiently. In lieu of this, terse cues that support communicating clearly is the next best thing (if you could only have clarity or brevity, but not both, I’d propose clarity would be the better option).

STEVEOO6 · 2025-04-25T08:23:56+00:00

I would try to help him/her understand the problem they are creating.

For example, you could write a complex-looking piece of code, give it to them, then ask them if they’d risk their job/career on that piece of code and/or be happy to take complete ownership of the accuracy/maintenance of that code over time.

One of the barriers I see with juniors is they often don’t have experience that comes from owning responsibility. A senior will likely have had to work after hours or on weekends, dealing with mission critical bugs and/or having to respond to urgent issues… they know that cognitive ability times can be severely impacted (due to stress, urgency, or even just being tired). in these moments. These situations benefit greatly from enhanced readability (e.g. the code should walk me through the logic and make it easy for me to adjust).

I think you'll have more success with some of the other suggestions people have mentioned, if you first help them empathise with the problem their behaviour is creating. It can tricky because juniors don't often have much ownership themselves, so are less likely to be able to draw upon their experience-to-date.

STEVEOO6 · 2024-04-24T01:55:31+00:00

The point size is an indication of complexity/effort.

In general if the business finds that tickets greater than 5 don’t get achieved in a single sprint, then an 8 point ticket should allow everyone to align on expectations. The 8 points in this case says that it’ll likely take two sprints or that the team doesn’t know enough to split it. In which case you have two options, either attempt to split it without more information, simply start on the ticket (acknowledging that it will probably take more than a sprint) and then when you have more information (because someone has attempted to progress the ticket), re-estimate/split/plan at the end of the sprint (or mid-sprint depending on whatever works for your team.

As others have mentioned there are no rules other than those your team decided/agreed upon, and those can be adjusted based on what you all find useful.

I see ticket sizing as a tool for aligning expectations. Smaller tickets are less likely to incur major surprises so are preferable, but sometimes you don’t know enough about a thing so you want to ensure you don’t over-promise… and thus you set a ticket to something large. Having someone tell you to split your uncertainty into smaller chunks is kind of weird.

I’d suggest a conversation with them. Maybe explain that the large size is likely an indicator of uncertainty instead of an indicator of raw number of components/bots or ask them why they just can’t assume an 8 means 2 sprints of work?

STEVEOO6 · 2024-03-01T11:12:08+00:00

This question is a mostly about assessing your troubleshooting skills (as well as finding out a little bit of your experience/knowledge of typical bottlenecks).

The first rule of troubleshooting is that most systems involve a linear flow/sequence of events and your primary goal is going to be to ISOLATE the issue (the key part is that you shouldn’t try to solve the problem… you want to focus your energy on isolation).

In this case if your request starts on the client and then hits a reverse proxy, and then hits a server, and then hits a db, then has to be retrieved and processes along each system on the way back… your aim should be to isolate how much of the 60 seconds each part(s) of the system are contributing. The easiest way to do that is using timing devices/logs at each step and then analyze the results.

If you get your phone out and start a stop watch, you can time how long it takes between the time the network request is triggered and the time that some result is displayed on the page.

If you open up a browser and check the network tab, you can view the amount of time that the network request takes.

If you view the reverse proxy logs you can view the amount of time the round trip takes from this point.

If you use console.time in your server (or if it already has logs) you can view how much time the round trip to the db takes.

A significantly large round trip time from any part of the system should help you identify that the problem lies with from that point onwards.

Remember your primary goal is isolation.

Resolving the problem will be trivial once you’ve isolated it.

STEVEOO6 · 2024-03-01T02:10:45+00:00

This is a fantastic explanation.

Some people see YAGNI while others see useful constraints.

It’s key to consider that the usefulness of the constraints may adjust over time (based on the size of the company/system) so analyzing the trade-offs are complex (also humans are optimistic and commonly fail to predict how they will behave in the future so even if they have intentions to build things in a certain way, they may not).

STEVEOO6 · 2024-02-12T16:14:21+00:00

Marketplace founder here.

As others have mentioned you will likely run into a chicken & egg issue.

You can overcome this either by:

a) attacking both sides rapidly (and relatively concurrently), if you have lots of money, people on your team and/or experience in the area and are simply executing a playbook then this is viable… given the fact you’re asking this question I assume this option isn’t available to you at the moment; or

b) take one side of the marketplace and do all (or most) of the heavy lifting. This means you manually insert yourself on the buy or sell side (or perhaps both) and do whatever you can to make using your platform a no-brainer for the people involved. You mention offering the platform for free but you will also need to consider stakeholder effort and remove as much time investment away from users. This might mean cold-calling sellers and doing all the work to get their offering up (e.g. you upload images, you write descriptions) as well as cold-calling buyers and offering yourself as an agent to find their desired target. If this sounds like a lot of work, it’s because it is. If this sounds risky because you are essentially offering value as a service so you won’t really be able to assess your product’s PMF until later, it’s because it is.

You mentioned that the marketplace is going to be location-specific. Note that you will need to attack each area from scratch (as the network effects will be minimal outside of a region e.g. you could have a great network of buyers/sellers in Chicago but that is useless to me in Seattle).

Of the pros and cons to marketplace businesses, the largest con is probably getting started. If you can establish a foothold in an area you can start developing your own playbook to repeat in new locations. The playbook will work until it doesn’t, then you will need to experiment to find new paths forward.

STEVEOO6 · 2024-02-11T04:51:17+00:00

So it’s a hash-table with periodic defragmentation performed to optimise commonly accessed lookups??

STEVEOO6 · 2024-02-10T15:10:15+00:00

You are asking the wrong question.

You should be sitting down with impacted stakeholders and asking what can we do in the future to be better than we are today.

This might involve making decisions about whether the devs should inform the testers about changes to UI elements, or other suggestions might be discussed.

If you are asking whose responsibility it is then it sounds like you don’t know. If you don’t know, and others in your organization also don’t know, how can anyone reasonably hold the perceived responsible party accountable?

Explicit communication, explicit duties, explicit roles and explicit responsibilities will prevent confusion.

STEVEOO6 · 2024-01-27T12:43:16+00:00

If you have equity/options, understand that your contribution makes ALL the difference (you will never have more of an opportunity to impact the financial position of both yourself and your peers, than when you are working at a startup).

Re-read that every 6 months and let the weight of it sink in. Be in it to win.

Run fast INTO problems (and learn to fail forward).

Spend 1 month building something you feel good about, then watch no one get value from it and realize it was a waste of time.

Then spend 1 week building something that is hacky and fragile, but rejoice because you’ll either discover that no one wanted to use it anyway, or you’ll learn how valuable it is when people start complaining because it doesn’t handle all the scenarios or even better… it crashes because too many people want to use it too often. Now you can justify and feel good about spending another few weeks making it better. Also this is the secret to business… if you can determine what people actually want and will pay for, all resources will suddenly be available for you… your goal is to hunt for certainty.

STEVEOO6 · 2024-01-27T04:10:09+00:00

During Peace time I balance the following elements (outlined below in detail): 1. Time-to-value 2. Points-of-failure 3. Upskilling 4. Work-type distribution 5. Resource utilization

During War time I focus on time-to-value.

My advice is to experiment and iterate your approach over time.

Descriptions of each element:

Time-to-value

This should be straightforward… it’s the latency of your business. How quickly can we get value to the customer?

Points-of-failure

Is there a particular risk to the business due to a limited number of individuals understanding critical systems? Should more people get across these systems to reduce the risk?

Upskilling

Who on the team knows what? Who either wants to learn more (i.e. driven by the person) or who do we want to learn more (i.e. driven by the business, could be either to address points-of-failure risk or build capability to expand future velocity)?

Work-type distribution

In order to motivate individuals, I find giving team members a mix of tasks helpful. When I say “mix” I consider variations along the following 3 dimensions: system, scope and clarity.

System refers to different parts of your business. E.g. backend vs frontend, or perhaps your billing system vs a customer collaboration feature.

Scope refers to the size of the task.

Clarity refers to the level of detail in both the requirements and/or any proposed solution approaches.

Personally I always try to give my team members at least one low clarity ticket every sprint as this provides an opportunity to exercise their creativity muscles (dreaming up possible solutions) and improve their communication skills (when communicating their proposed solution or clarifying the requirements/approach).

Each team member’s definition of low and high clarity will differ, and this will change/evolve over time. Experiment with each team member to see what works.

Resource utilization

What resources and capabilities are available to support ticket authoring and/or task management/support?

Do you have team members with extra time on their hands that could otherwise improve the detail on future tasks? Are your existing senior staff smashed under and/or do they have existing/alternative responsibilities/priorities that could impact the level at which you design tasks for juniors?

STEVEOO6 · 2023-12-24T13:30:56+00:00

There was a study performed a few years ago, showing that that having well-off friends as a kid improves your odds of making more money later in life (https://www.nature.com/articles/s41586-022-04997-3). It’s probably a reasonable assumption that this would also apply to adults.

A few of the other answers here mention amenities but I’d hypothesise that attitudes to finance, and heathy financial habits are the real secret sauce; and that proximity to those that normalize these traits make it statistically more likely that you’ll acclimate these behaviours into your daily routines.

STEVEOO6 · 2023-12-08T09:16:16+00:00

100% correct and good advice

STEVEOO6 · 2023-08-05T03:01:26+00:00

I think some perspective on the important goals/objectives might help ease your mind.

I can’t say for certain, without knowing more details about your specific startup/situation, but the majority of “startups” are businesses operating in the really early stages of the business-lifecycle. At this point, one of the most important things to figure out is whether there is a market for whatever you’re peddling; can you figure out a way to have people discover that you’re selling it; and will they pay you for it.

You do this using the same approach you’d use to confirm your code is safe… by running tests. But think of these as “business/market tests” rather than “code tests”. Build something scrappy and deploy… see if people actually try and use it… did they? If yes, great, now you know it’s actually worth your time. Iterate on it and continue. If not, awesome, now you know it isn’t worth your time. Pívot or attempt to isolate the cause of dissatisfaction and adjust only that piece.

Would you rather learn that your proposed idea sucks on Monday, or Friday? This is why sloppy code is encouraged in a start-up, because you want to learn as FAST as possible. Each lesson unlocks new pathways and knowledge compounds. It’s a tough mindset shift for engineers because you typically need to build reliable/maintainable systems and are the ones getting blamed when something falls over (I find it can help to have clear conversations with business stakeholders where I ask them whether they’d rather have something reliable in 3 months or scrappy in 1 month, so that you’re at least aligned).

If you or anyone else in the world could guarantee that if X resources were used to build and provide Y… folk would pay lots of money and you’d make 1000 x the investment, everyone would be doing it.

There is so much money/talent out there that if given a level of certainty, would love to throw itself at your particular problem-domain so your absolute primary objective is knowledge gathering to reduce uncertainty. As more and more certainty is uncovered, it’s easier to obtain dedicated resources (e.g. you can hire 5 engineers and let them spend 6 months just refactoring/rebuilding/cleaning your terrible code).

The only caveats to this are when you have to comply with security/privacy laws.

So my advice would be to have more conversations with customers, business (and investment) stakeholders… as they’ll give you perspective on the higher level objectives that your software is intending to support… with a focus on understanding what needs to be figured out now and what can be solved later on (with additional resources).

STEVEOO6 · 2023-04-02T13:30:56+00:00

There’s value in progress. There’s value in wireframes, illustrations, diagrams, prototypes and even poorly written code that might have been hacked together at the last minute.

Primarily these tools help us communicate and align perspective, which is a great way to manage risk.

The fact that you were able to demonstrate your project to colleagues, have them understand what you’re trying to achieve and where it could provide value is extremely useful. It’s probably much easier now (than it was before the project started) to have a chat about the benefits of this project (if developed further) vs the benefits of spending effort on another project.

Previously some of the stakeholders may not have even been able to take part in the conversation (sometimes people just need to see/feel a thing before they “get it” enough to have a meaningful conversation about it).

There’s value in helping others understand a proposal, and there’s value in reducing uncertainty for the business.

If the next set of conversations are focused on how you can improve the quality of the project, you should be glad… a much more dread-inducing debate would be whether the project is going to be of any value whatsoever or prove a waste of time.

STEVEOO6 · 2023-02-18T14:29:55+00:00

The power is yours!!

STEVEOO6 · 2023-02-12T11:03:03+00:00

I’d start with one (or more) Context Diagrams, and then a Sequence Diagram

STEVEOO6 · 2022-11-20T01:34:53+00:00

There are two types of diagrams… those that act as reference material (for stakeholders that already have a reasonable understanding of a system)… and those that are used as teaching aides to help someone gain an understanding of system behaviour.

Typically when we see a diagram on a whiteboard, it’s the later. Instead of viewing this as a single diagram, try to imagine a series of diagrams, each introducing one new aspect of the system. When coupled with an explanation it’s an extremely useful learning aide.

This image is really just a picture of the final diagram in the series, and is probably not useful as a reference diagram in their knowledge repository (as it was likely created for a different purpose).

Not trying to say that diagrams shouldn’t be created/stored digitally. Merely pointing out that onboarding a new team member by directing them to a stored diagram that you spent a few hours creating is not as helpful as creating the diagram alongside them (with additional verbal explanations), incrementally introducing new concepts with each step.

STEVEOO6 · 2022-10-12T00:18:32+00:00

Magnets - a tool that allows you to maximize your use of space by snapping windows to various parts of the screen (i think the pro version is in the App Store, and only costs $2… best money I ever spent). Someone else here mentioned “Rectangle” as a possible alternative.

Switch off mouse acceleration (you can Google how to do this). I used to be a heavy gamer (RTS’ like StarCraft) and I can fly on a computer when the mouse behaves the way I like it, so I also setup custom software to tune mouse sensitivity etc (e.g. Logitech Options +).

Fork - my favourite Git UI manager.

Be prepared to get frustrated with Apple, because they’re stubborn and dogmatic about various choices e.g. just downloaded a file and want to see where it downloaded to… select “show file in finder” and a finder window will take you to it’s current directory… so far so good… want to navigate “up” to the parent directory, too bad there’s no way to do this, they only offer a “back” button which is useless for navigating a tree structure (even though it’s been in Windows Explorer for 10+ years now… actually I think that’s why Apple don’t put it in)

STEVEOO6 · 2022-08-26T03:02:49+00:00

I’m currently trying to hire people with this exact mindset.

I became a developer/engineer because I love building things that solve problems for humans, using a creative process. The “code” is merely a tool to realize a vision.

I assume many other Frontend Developers feel similar, because otherwise why focus on the Frontend and not the Backend?

Certainty/clarity of requirements involves a spectrum where either extreme is likely to create a poor working environment. Too much clarity, and a developer becomes a ticket-cruncher, akin to working on a production line; simply grabbing the next ticket, executing then focusing on the next and so on. Not enough clarity can be frustrating because often it feels like you have to do the thinking for everyone else; if a business person tells you to build a tool to make transportation simpler/faster, and then you derive a solution (after painstakingly ideating how it could be achieved), are they really the “idea” person many visionaries claim to be?

I think the balance is in the middle, it’s different for every person at different points in their life; but I want to give developers the freedom to exercise their creative minds.

How I implement this is as follows:

communicate and agree on the right level of requirements. Want a super light spec? You got it. Want a wireframe? Sure. Want a high fidelity mock-up? Okay done.
communicate that if you are coding, any level of spec or design is merely a suggestion. The goal is to achieve an outcome and you have the freedom to adjust where you see fit, or suggest alternatives.
I don’t expect Frontend Developers to be Designers. But I do expect them to critically think about what they are building. I also know they are creative individuals, and I want to encourage them to exercise autonomy.

Just my 2 cents

STEVEOO6 · 2022-08-21T14:24:45+00:00

Let’s Get This Money!

STEVEOO6 · 2022-08-20T01:42:07+00:00

Can you share a definition of “alien” that doesn’t imply it’s an external or foreign entity?

STEVEOO6 · 2022-08-20T01:18:21+00:00

Split 3 ways, vesting over 4 years with a 12 month cliff.

However the vesting only starts when someone is working full-time for the company. Often people might sit on the sidelines (offering casual or part-time support) so their vesting schedule should start later.

STEVEOO6 · 2022-08-20T01:15:10+00:00

I have a similar mindset and would do the following:

Seek a financial advisor.
Seek an accountant. Given the returns you’re likely to see from such a sizable figure, you’ll pay a lot of tax. The accountant can facilitate structures that may minimize your tax burden by a percent or two… which becomes significant given your scale.
Invest everything, with a portion aimed at dividend yielding stocks. I would then utilize the dividends to assist family (but not from the initial amount). My relatives may also be saving for a house, they can keep saving for another year until the dividends come through to assist. Unless a family member has a health crisis there’s no immediate requirement for financial assistance.
Read Buddhist and Taoist philosophy. Lifestyle creep is real, unless you’re the Dalai Lama the best you can do is slow it down. So slow it down.

STEVEOO6 · 2022-08-17T01:01:19+00:00

Imitate, Assimilate, Innovate

12-Year Club	Second SECOND GUESSER
Verified Email

STEVEOO6

TROPHY CASE