Getting to Conscious Competence Getting to Conscious Competence Getting to Conscious Competence

This is my note on the book The Missing README by Chris Riccomini Dmitriy Ryaboy chapter 2: Getting to conscious competence.

Be competent in these facets

1. Technical Knowledge

• CS fundamentals
• Use of IDE, build systems, debuggers, and test frameworks
• Familiar with CI/CD, metrics and monitoring, configuration, and packaging systems
• Proactively create and improve test code
• Consider operations when making architectural decisions

2. Execution

• Understand the connection between your work and the business
• Build and deploy medium-sized features
• Write, test and review code
• Share on-call duties and debug operational issues
• Participate in technical talks, reading groups, interviews, and presentations

3. Communication

• Communicate clearly in verbal and written form
• Give & Receive feedback effectively
• Proactively ask for help and clarafication in ambiguous situations
• Raise issues and identify problems constructively
• Provide help to peers
• Document you work

4. Leadership

• Work independently on well-scoped work
• Learn from mistakes quickly
• Handle change and ambiguity well
• Actively participate in project and quarterly planning
• Help new team members onboard
• Give meaningful feedback to your manager

The 4 Stages of Competence

1. Unconscious Incompetence
2. Conscious Incompetence
3. Conscious Competence: You are capable of performing a task with effort
4. Unconscious Competence: You are capable of performing a task effortlessly

Your goal is to get to conscious competence ASAP

Tips for learning

1. Upfront learning before shipping

2. Learn by doing

3. Experiment with code

• Run code in experimental (not production) environments
• Experiment by throwing an exception, printing a stack trace, or attaching a debugger to see the call path
• USE DEBUGGERS A LOT!
• Sometimes, use print statements (distinctive print that tell it’s a debugging print) instead of debuggers

4. Reading

• Spend a portion of every week reading
• Team docs, design docs, code, tickets, books, blogs, papers
• Pay attention to trade-offs under certain context
• Read high-quality open source code, particularly libraries you use
• Don’t read line by line. Instead, use AI/IDE to navigate
• Diagram control flows and states for key operations
• Dig into data structures and algorithms.
• Pay attention to error handling
• Read history tickets
• Books/Papers are structured and deep but could be outdated; Online content is new but may be less trustworthy

5. Watch presentations.

• Recorded videos
• Tech talks
• Conference presentation

6. Attend Meetups and Conferences

7. Pair programming with experienced engineers

8. Experiment with side projects

• Participate in open-source projects
• Experiment with new tech and ideas
• Don’t use company resources on side projects.

Tips for asking questions

1. Do your research

• Try to find the answers yourself, even if your colleagues know the answer
• Search the Internet, wikis, READMEs, source code, bug trackers
• turn your question about code into a unit test

2. Limit how long you research a question before asking

3. Show what you have discovered when asking

• The tests you’ve run and their results
• Your discovery in the source code

4. Don’t Interrupt

• Don’t interrupt your colleague when they are in the zone

5. Prefer Multicast, Asynchronous Communication

• Ask in a group chat where the conversation is archived for later search
• Multiple people can respond to you

6. Batch Your Synchronous Requests

• Asking questions face-to-face in batches

Imposter Syndrome and the Dunning-Kruger effect

Imposter syndrome is so common among new engineers. It’s normal to feel behind everyone, and such belief is self-reinforcing. Every error is seen as proof of incompetence, and every success is evidence of a good “faker”. Awarness helps with getting out: When you achieve something, it’s because you actually achieved it, not just because you’re getting lucky. Your peers are capable, and if they say something positive, they have good reason to.

The Dunning-Kruger effect happens on unconscious incompetent engineers, when they don’t know what they don’t know. They believe they’re more capable than they actually are. Their default mode is to push back or disregared feedback.