As an engineer, you must retain an endless amount of business and technical knowledge while keeping your memory updated with new features and mashing preexisting connections with new ones.

When changing companies — especially in a new industry — even more so. If you’re a seasoned engineer, you have technical expertise but lack business knowledge. At the end of the day, that’s what truly matters.

When you’re younger and still gaining experience, technical skills and challenges drive you forward. You soak up as much knowledge as possible, diving deep into how systems work and how programming languages and frameworks help solve problems.

As I became more familiar with the tech skills, I realized that I was no longer looking for the next optimization, refactor, or “cool” challenge. Instead, what keeps me interested is how I can use my skillset to create products and ship features.

I should note that this is my personal experience. I enjoy building products and features. If they’re technically challenging, that’s a bonus—not the goal.

Note: I still overengineer and overcomplicate my releases (bad habits), but that’s a topic for another thought.

The “Management” Problem

With that said, I’ve come to face a “management” problem — so to speak.

Before starting any significant piece of work, I enjoy the investigative process: discussing, exploring, and thinking through edge cases (which I’m terrible at), and last but not least, planning!

The “investigative work” as I’m calling it, is about understanding the feature’s interactions throughout the system:

  • What approach to take?
  • What is the impact of that approach?
  • Will it require changing other parts of the system?
  • What are the edge cases?
  • What are its pros and cons?
  • Is there a simpler way?

Thinking about edge cases is hard for me. The reason? First thought that comes to mind is that I’m constantly switching industries. None of my previous jobs have been in the same vertical, and each new company I join does something completely different from what I was used to.

At least that’s my excuse.

And that’s my own fault. But I don’t regret it.

I enjoy learning and experiencing things from different perspectives. It keeps life interesting and never dull. It also exposes me to products I didn’t even know existed — or had real use cases.

I bet you have recently encountered a product or app that made you think, “What? How come people buy this?!”

Planning and Execution

The planning phase is about taking all this raw information — business requirements, technical analysis, proposals—and breaking it down.

How do I take this big ball of information and start doing the work?

The good ol' divide and conquer.

Create a ticket with all the information and try to extract small, actionable pieces so you can:

  • Work on smaller chunks
  • Open smaller PRs
  • Iterate & ship faster

Easier said than done.

I did this fairly well at SellerCrowd. We all took turns leading new features, and each of us (a team of five) was responsible for splitting the work.

But I lost the skill. And I want to get it back.

The “hard” part

Right, so you do all that. You break the work down, build the feature, and ship it. You discuss on a daily what you’ve been up to, how your feature works. Then a co-worker asks:

“Hey, it seems the feature isn’t doing XYZ like we discussed?”

Bam, I forgot to handle XYZ.

This is the not so easy part - for me.

At this point, I try to explain my thought process — also known as fumbling my way through a plausible enough excuse — also known as f$%k f$%k f$%k.

The team discusses. I listen. Occasionally throw in my arguments. Meeting ends.

I fix my implementation.

Next daily comes up, I explain I fixed XYZ. Somebody remembers another detail I forgot….

How is this possible? Am I incompetent? I tried so hard and still fumbled?

This is the scenario I struggle with: properly applying all the requirements and edge cases that I planned, I discussed, and I wrote down.

So, how do I get my $#%! together?

Writing tests? Sure. But I can still forget to write tests for certain cases.

I’ve gathered some ideas (thanks to a mix of LLM magic and good ol' Google).

Before implementation

In the top-level ticket, I could start writing:

  1. Implementation checklists: convert requirements into checkable steps (checkable? who says that? an LLM for sure)
  2. Acceptance criteria: define expected outcomes for the feature
  3. Edge cases: write down what they are, and how to handle them
  4. Definition of done: what constitutes “done” for this feature?

Voilá, a workflow framework.

Am I a manager now?

But there’s more!

During implementation

Leave reminders. Write more TODOs**. As you code through the sub-tasks, leave TODOs referencing pending work.

After implementation

Record a demo (max 5 min) – Walk through the feature. If there’s no UI, talk about:

  • Entry points in the code
  • Where the main logic lives
  • Important interactions between services
  • Expected outcomes/results

In theory, this should help me catch mistakes earlier and ensure nothing slips through the cracks.

Habits take time to build, and no system is foolproof.

Will it work? Will I stick to it?

I hope so.

If I can reduce the number of “oh crap, I forgot that” moments, that’ll help me sleep better at night and not “dream” about being fired

.

.

.

.

.

.

.

No, I have absolutely never dreamed about being fired due to my imposter syndrome. Not ever.