No intro, we're just diving in.

1. To reach intelligent answers, you often need to ask dumb questions.

Beginner devs often lack the full context of what they are working on.

I fell victim to this early in my career. I was tasked to build a forecast model of one of our company's suppliers. I said "yes" and got to work.

But I had no idea how to do it.

I barely knew what a supply chain was. Let alone material requirement planning (MRP) or bill of materials (BOM). I spent days researching Wikipedia and YouTube trying to essentially give myself a makeshift Master's Degree in Industrial Engineering.

I built what I thought they wanted based off of my haphazard understanding. I was ashamed. They said "This isn't what we wanted. This isn't useful to us."

I had too much ego. I wasn't willing to ask the dumb questions to the right people.

If I had asked the dumb questions, I would've drastically sped up my time to delivery. I would've gotten relevant info, proper requirements, and specific knowledge.

Instead, I chose to appear as the Genius Developer: a sole coder who could do no wrong.

In the end, I did everything wrong. My tech lead had to step in and redesign it from scratch. I watched in real time as he asked idiotic questions - but he got the right answers. And built a proper, working solution.

2. The opposite of a good idea can also be a good idea.

Which of these is the best idea?

• Implement a microservice-centric tech stack with to handle scale and decouple complex architecture.

• Implement a monolithic tech stack where all code lives in a single codebase.

The answer? Both.

Or more accurately, it depends on the context.

If you're Netflix, you want a complex web of microservices to handle hundreds of millions of users.

If you're a costing application for a small business, a monolith will do nicely.

Beginner devs get caught up in trends, best practices, and shiny object syndrome.

It can be tempting to cut over a monolith to a microservice-heavy architecture. You'd learn a lot. It'd be cool. Your application might run faster.

But you also lose a lot of the robustness, ease of change, and slow down onboarding.

Understand your context and make decisions from that - not the latest trends.

3. The best ideas do not emerge within disciplines, they emerge at the intersections between them.

Beginner devs love to code.

This is great! But when it's their only love, they halt their career growth.

New disciplines and interests broaden your horizon. They introduce you to new ways of doing things. New ideas, perspectives, and experiences.

Plenty of devs I know work full time for a company, then turn around after work and hack away at personal side projects. Code, code, code.

If you're trying to speed-run your career, think which might be more attractive to management:

1. A coder who codes in their free time.

2. A coder who does improv and volunteers at a non-profit in their free time.

While Coder #1 may be a subject matter expert, it's unlikely that they will get very far purely on technical merit.

Coder #2, however, has a few more skills they can draw on:

• Improv is a great training ground for soft skills: communication, connecting with people quicker, being adaptable, having empathy, the list goes on.

• Volunteering shows a gracious and giving spirit.

• Non-profit work highlights understanding of different business contexts.

It's important to remain true to yourself in your interests.

What interests you beyond coding? Go do more of that. You'll be surprised what you learn about yourself.

4. Never call a behavior irrational until you really know what the person is trying to do.

The amount of beginner devs I see complain about other people in the business (PMs especially) is too damn high.

If we assume everyone is a rational egoist acting in their self-interest (instead of trying to make your life worse), then there must be a reason PMs do what they do.

Ask yourself:

• What incentives are they measured on?

• What is their role in the business?

• What is MY role in the business and how does it compare to theirs?

• What unseen work are they doing that I'm not appreciating?

Ask questions - don't make assumptions.

5. What gets mis-measured gets mis-managed.

Beginner devs want to dive headfirst into code.

They see a problem and start building a solution in their head. They don't get all the context - nor do they measure the "before state".

This is a HUGE waste of career potential.

Yes, skipping measurement phases is a great way to speed up time to solution. And sometimes that's worth it. But not always.

Quantifying your efforts is the best way to speed-run your career.

Imagine taking a couple of hours to get a pulse on how a current process is done. Maybe it takes 3 hours/week for 2 $40/hour employees to input data into a spreadsheet. Now picture yourself automating that - now it takes 5 minutes with the click of a button.

Which do you think management would prefer:

• "It used to take 6 weekly man-hours for this process. I automated it to 5 weekly man-minutes. That's a 7,200% productivity increase which translates to $12,000 saved per year."

• "We didn't measure the 'before state' so I don't know how much time we saved, but it's so fast!"

Take the time to measure during the process. At the very least, measure the before- and end-stages.

6. It's not enough to be right, you have to be persuasively right.

Beginner devs love to be right. Oftentimes, they are!

But their discoveries don't always translate to non-devs. They lack the art of persuasion and catering their message to their audience.

The quickest way to fix this is to focus on outcomes, not process.

Nobody knows what "coupling API integrators to a Kubernetes cluster via Postgres using SQLAlchemy to fortify a monolithic infrastructure" means. You probably skipped that whole sentence.

What is the result of what you did?

• You didn't "couple API integrators". You saved Jenny, the accountant, 2 hours / week in manual processes.

• You didn't "use SQLAlchemy". You standardized database protocols, reducing new project start-up time.

• You didn't "fortify a monolithic infrastructure". You reduced the potential of a disastrous bug which could bring down the whole system.

State your outcomes, not your process.

These lessons come from Rory Sutherland, a British advertising executive at Ogilvy.

👋 Hey, I'm Gus, developer, improviser, and game maker.

🥰 If you liked or were surprised by this article, consider sharing it.

🚀 LinkedIn (bite-size-blogs) | Twitter (say hey!)