In a nutshell

• In my previous post, "Why I Hire for Depth (as a VP of Engineering)", I discussed why the ability to understand things in-depth is critical for a developer.

• Today, I'll share 4 powerful techniques for deeply understanding any topic.

Nothing can replace working with an experienced team on real-life, long-term, complex projects.

However, even this kind of experience doesn't automatically result in deep understanding if you aren't intentionally seeking to deepen it.

So how do you pursue depth?

Here are my 4 favorite techniques:

1. Explore the boundaries

Push good practices to the extreme.

If functions with fewer parameters are considered good, how would your code look if no function had more than one parameter? How would it look like if no function had any parameters at all? Would it even be doable? What workarounds would you have to implement to make this possible?

The most interesting things — and the most learning — happen at the edge cases. To fully understand how and why something works, you must understand when it doesn't work anymore.

Consider also the opposites. Can you think of any edge case (even if a bit unrealistic or crazy) where a function with a long list of parameters would work better? Why would it?

No principle is universal. No principle always works. Stretching it, stress-testing it, discovering its limitations is the only way to understand it in-depth.

This can be done in two ways: through mental or practical experiments.

You can just imagine or discuss with your teammates how your code would look if all the functions had zero parameters.

Or you can challenge yourself to write only zero-parameter functions for the next week and see what happens. Code is extremely malleable, so such experiments carry no risk — you can always easily roll it back.

2. Search for criticism

For every "best practice", there will be naysayers and critics.

Some will feel close to the truth but slightly off. Some will feel almost blasphemous.

Embrace both groups.

For the "slightly off" ones, consider why they see things this way. What nuance do they miss? Can they see something that you don't? How is their context different from yours? Could they be correct in their context?

For the "blasphemous" ones, consider why they see the world so differently. What may be their underlying assumptions? What are yours? What experiences could lead them to such a wildly different perspective?

Finding naysayers is easy. Just Google phrases like "Why I no longer use X", "Why X is dead", "Why I hate X", and similar. Or post a provocative comment on social media and check the replies.

You can also play the devil's advocate yourself. Wear a contrarian (or even extremist) hat for a little while. Ask "What if?". Play the critic. You'll be surprised how much deeper and more nuanced your point of view will become.

3. Understand the original context

No "best practice" is born in a vacuum.

It always stems from a solution to its creator's pain point or emerges as a common pattern observed in its creator's environment.

You will never understand the practice in-depth if you don't understand when, why, and in what circumstances it was created.

And this information gets obscured over time. If a practice is popular, it will be synthesized, summarized, cloned, and adapted — and also misinterpreted and distorted — to the point where decrypting the original context becomes impossible.

But it's not that hard to find the practice's creator and the publication where it was first introduced.

Read it for the original context. Then, consider how the industry has changed since then, what's the current state of the art that wasn't available at that time, and how your particular context and pain points compare to those of the practice's creator.

Compare it also with the most up-to-date publications on the topic, especially "official" ones (if the practice is still backed by the original creator or some organization). Is it preserved intact or has it evolved? How? Why do you think it has evolved this way? What turned out to be evergreen and what had to be changed to keep up with the industry?

This will not only help you understand the practice in and out but also anticipate how well it will fit your case and how easy it is to tweak.

4. Consider how something will scale

Technologies, methodologies, and best practices often have a sweet spot regarding scale.

And I mean scale in a broad sense, not only the number of requests: more developers and teams, bigger codebase, more complex architecture, more features, more customers, more markets.

For example, will a particular deployment pipeline work equally well for a monolithic project and multiple microservices? A single Git repository, multiple repositories, and a monorepo with multiple projects? One team deploying a few times per week, and 20 teams deploying several times per day? A single geographical cloud region and multiple?

Or will a methodology like Scrum work equally well for a single person, single team, multiple teams working on a single product, and multiple teams working on a portfolio of products with many stakeholders and types of customers?

How easy will it be to adapt or replace a given technology or practice to accommodate various aspects of the product and company scaling up?

Considering questions like these will greatly deepen your knowledge and help you make more future-proof decisions.

Bottom line

Applied regularly, these 4 techniques will let you understand any topic in and out — and shine in your next interview. Plus, you'll become a much better developer.

To make it clear: I don't want you to become a software engineering philosopher, spending days and weeks contemplating the subtlest nuances. Be pragmatic. Be practical. But also don't shy from diving deep.

It doesn't take much. A quick mental experiment. An occasional discussion with your teammates. Paying more attention to critics. More deliberately choosing which books to read. You'll be surprised how much depth you'll gain — and how quickly.

In a nutshell

• During interviews, I meticulously assess how deeply a candidate can understand and discuss their technical decisions.

• It can range from "because my tech lead said so" to a nuanced understanding of possible alternatives, their tradeoffs, and the consequences of the choice.

• I prioritize depth over direct skills for several reasons, which I discuss in the post.

• I don't like typical coding tests because they don't reveal depth.

How I interview

My interviews start with an open-ended conversation about the candidate's experience, interests, and preferences. This usually reveals areas they are passionate about, have extensive experience in, or where they have had to make significant decisions.

And then I drill deep.

Suppose a candidate mentioned they chose MongoDB as the data store for a new project.

I'll then dig:

• What led you to choose a document-oriented database over other types like relational or key-value?

• What led you to choose MongoDB over other document-oriented databases?

• Is MongoDB your default preference, or was it the best fit for this particular project? Why?

• What tradeoffs were involved? What did you have to sacrifice? Why do you believe the benefits outweigh these drawbacks?

• Why were these specific benefits important for the project?

• Could they have been achieved through other means, not involving MongoDB?

• How did you mitigate the drawbacks?

• Would it make sense to use multiple data stores? What would it solve? What would it complicate?

• Is this solution short-term or future-proof? How will it scale with the load? How will it scale with increasing load, team size, and data complexity?

And so on... You get the gist.

And then, based on the candidate's responses, I'll probe even deeper.

For example, if the candidate mentioned choosing MongoDB over other document-oriented databases because it is easier to self-host, I might explore:

• Why do you prefer a self-hosted solution over a managed cloud service?

• What are the risks and benefits of self-hosting?

• How have you addressed these risks?

And so forth...

While interview time is limited and it's not possible to explore every angle, my goal is to assess depth rather than breadth. Therefore, it's ok to select just a few paths and gauge how deeply the candidate can delve into them instead of trying to cover as many paths as possible.

This approach effectively reveals the depth at which a candidate operates.

The 5 levels of depth

Depth is a continuous spectrum, but to illustrate how different candidates operate, it's convenient to group it into five broad levels:

1. Knows just one way. The candidate lacks personal opinions and is unaware of alternative approaches. Asked about their choices, they typically respond "Because we used this in my previous company" or "Because my tech lead recommended it".

2. Blindly follows best practices. The candidate keeps up with industry news and is aware of multiple alternatives. However, they follow the best practices blindly. Asked about their choices, they typically respond "Because such and such book or blog said so" or "Because Google and Netflix do this". However, they struggle to discuss the tradeoffs, especially the ones specific to their project.

3. Makes own decisions, but shallow. The candidate knows the alternatives and makes intentional choices among them. Their reasoning, however, is shallow and they typically talk in generic terms. For example, they might say they chose MongoDB because document-oriented databases are more flexible than relational ones, but they won't be able to discuss the tradeoffs, limitations, edge cases, or potential issues.

4. Makes deep and nuanced decisions. The candidate not only knows the alternatives but understands their strengths, limitations, ideal use cases, and boundaries. They make well-informed choices with comprehensive consideration of all pros and cons, tradeoffs, and consequences—and know how to mitigate the drawbacks.

5. Understands also the full context, and second- and third-order effects. The candidate grasps all nuances of their choices, including the origins of the technology and the problems it was designed to solve—and how well they translate to the particular project's context. They consider not only the direct impact of their choices but also the potential long-term effects on the codebase, team, processes, and subsequent decisions.

From a seasoned senior developer, I expect at least a Level 4 discussion.

It’s important to note: I don't expect such depth on every topic.

Some topics are straightforward. If a candidate prefers function brackets on the same line rather than a new line, saying that they find it more readable or aesthetically pleasing is more than enough.

Some topics are well-established. I don't expect a candidate to know the entire history of HTML or to provide an in-depth explanation of why it is used in web applications.

Finally, I don't expect a candidate to know in-depth and be opinionated about every technology ever made. If a candidate says their team chose MongoDB but they weren’t involved in the decision because they lack interest in databases—fine with me. The greatest strength of an outstanding developer lies in their ability to effectively research and learn as needed, not being a know-it-all.

However, if a candidate claims to be a proponent of a specific flavor of microservices, and has influenced their team to adopt it—then we'll go Mariana Trench-deep on this topic.

And while I don't expect equal depth in every area, a senior developer should be experienced or interested that deep in at least a couple.

The quality of the discussion matters, too

An important side note: As a professional developer, you'll be involved not only in making decisions—but also in explaining, discussing, selling, evangelizing, documenting, and arguing about them.

That's why not only the quality of the decision (and the considerations that went into it) matters. The quality, flow, and clarity of the discussion itself are equally important.

Why is depth so important?

Depth is strongly correlated with several desirable traits in a developer:

• Better decision-making. Their choices are more thought through, better tailored to a specific use case, well balanced, and consider all the subtle but critical details.

• Safer decisions. They think not only about the here and now but understand second- and third-order effects and the long-term consequences of their choices.

• Resistance to hype. Their decisions are based on thorough analysis and merit, not on current fads or some influencer's opinion. They also better understand the long-term risks of getting locked into a wrong choice.

• Ability to solve new, unique problems. Which is what software development is all about—and is impossible with only superficial knowledge. A high level of depth proves curiosity, diligence, exploratory skills, and ability to get to the root of the problem.

• Positive impact on the whole team. Ability to understand problems deeply—and then explain them simply and clearly—makes them a fantastic mentor. They will expand the team's horizons and bring it to a new level.

• Enjoyable to work with. Deeper discussions and more nuanced points of view are more interesting.

• No zealotry. A high level of depth and nuance indicates open-mindedness and a lack of bias. This means making the best decisions for the company, not trying to force their way. It also translates to being more open toward their teammates' diverse worldviews, which makes them more pleasant to work with.

• Future-proofness. Depth confirms an affinity for learning (which, together with problem-solving, is the second pillar of what software development is about). This makes them more adaptable and better equipped for inevitable change.

• Aptitude for working with "business" and customers. Their affinity for depth makes them better at understanding requirements and addressing customer needs. And their communication skills help them discuss and "sell" their ideas to non-technical stakeholders.

• Aptitude for teamwork. Their open mind and appreciation for ambiguity and nuance, make them better at considering and reconciling multiple opinions. And their ability to synthesize and clearly explain complex ideas enhances their impact on the team even further.

Bottom line

Depth is a strong indicator of a great developer. That's why it's one of my primary recruitment criteria—and why I probe so hard for it during interviews.

It's also why I don't like coding tests. They showcase the final result but not the research, learning, reasoning, synthesizing, discussing, and negotiating that would go into it in a real-life project. They test ability but not depth.

Under the tight time constraints of an interview, depth can only be assessed through a deep discussion.

P.S. In the next post, I'll share a few techniques for building deep knowledge on a technical topic. Stay tuned!

📣 The sixth chapter of my "Definitive Guide to Succeeding as a Professional Dev" is now out!

It discusses how to impact your whole team or company even if you aren’t an official manager or tech lead—and no matter your seniority level.

📖 Read it HERE

Or, if you need a refresher, check the full table of contents.

PS: If you find the guide helpful, don't hesitate to share it!

🫶

Wojciech

I'm satisfied with my career. Over the years, I've consistently advanced professionally, to senior, lead, and finally VP. Along the way, I was able to steer my career as I wanted, switching between roles and technologies that interested me, delving into coding, tech leadership, agile coaching, and management.

I also learned a lot, and without these insights, I'd never have gotten to where I am now. However, if I had known them sooner, it would have saved me a great deal of frustration and accelerated my progress by several years.

It's impossible to compress all the learnings from 22 years in the trenches into a single blog post (for a more comprehensive take, check out my "Definitive Guide to Succeeding as a Professional Dev"). But I've selected the 22 most crucial insights that I wish I had known earlier in my career.

On the nature of software development

1. Software development is so much more than just coding.

Don't dig yourself into the narrow hole of being just a hacker (no matter how brilliant). Coding is only a fraction of what software development is about. A well-rounded senior dev has to be equally good at teamwork, communication, managing projects, managing their own time, analyzing requirements, understanding new business domains, prototyping, iterative development, and a ton of other "soft" and "process" skills.

These skills don't come naturally and require as much deliberate learning and practice as coding. But without them, you'll never be seen as a true senior dev. And you'll never advance your career past the point of a mid-level individual contributor.

2. Software development is all about working with people.

There's no place for lone geniuses in professional software development. Modern software is built by tens, hundreds, and thousands of people - and for people. This means working with your team, other teams, management, business stakeholders, and users. Even as a single-person indie studio, you still have to interact with your customers, influencers, and the press.

Getting good at people skills (emotional intelligence, active listening, empathy, conflict resolution, negotiation, building rapport) is fundamental for a successful software development career.

3. The key coding principles to learn are those that stem from human cognition.

Code is written mainly to be read and modified by humans. And the human brain hasn't changed for millennia.

Principles stemming from the current era's computer architecture and popular tech stacks change with every new tech iteration.

Principles based on how the human brain works - like encapsulation, readability, cognitive load, or levels of abstraction - are universal, timeless, and transferable. Focus on mastering those.

4. There aren't many new paradigms in programming.

The landscape of programming languages, frameworks, and libraries changes at a breathtaking pace. However, very few of the underlying paradigms are new.

Functional vs object-oriented. Asynchronous vs synchronous. Centralized vs distributed. Concurrent vs sequential. Caching vs processing on-demand. Fundamental concepts like these don't change much at their core and are highly transferable across tech generations and stacks. Whether you use Actors, Coroutines, Channels, or Threads, concurrent processing principles stay the same. And regardless of which application layer requires caching due to current hardware characteristics, similar principles of handling stale content and cache invalidation still apply.

Understand the fundamentals thoroughly, and you'll build a solid, future-proof foundation for quickly learning any new technology or language.

5. Most of the code is legacy code.

Software development is a team game and most of the software is long-living. This means that the majority of the code you'll ever work with was either written by someone else, modified by someone else since you wrote it, or written by you too long ago to remember the details.

Working effectively with legacy code - navigating, understanding, modifying, and improving it - is the most critical coding skill to learn, as early in your career as possible.

6. Almost everything can be gradually refactored.

Code is inherently malleable. Even the most spaghetti of codebases can be improved gradually over time. Especially if you are skilled in proper "safety net" techniques: rigorous refactoring, characterization tests, and so on.

"Freeze and rewrite" is almost never a good strategy. It is painful for developers and dangerous for the business. Unfortunately, it's one of these things most of us have to live through at least once to acknowledge. But please hear me out. 🙏

7. Code aesthetics aren't important.

Every programmer, at some point, becomes enamored with a particular syntax, often to the point of a religious dispute over which language, framework, or coding convention is prettier.

Please, don't!

Choose your tech stack based on the career opportunities it'll open for you. Choose it because of domain-specific strengths, like being optimized for massively concurrent processing. But don't choose it simply because of its elegant syntax.

And never ever waste energy, time, and the good will of your new team by whining about their established coding standards just because you prefer a different way to use semicolons or brackets.

Beauty is in the eye of the beholder. It's the high-level architecture, readable code, tooling, and domain fit that make you productive, not the trivial syntax details.

On learning and reinventing yourself

8. Learning is THE most important skill for a software developer.

The pace of change in today's world, particularly within the tech industry, is staggering. Since I started university 27 years ago, we've seen the rise of the internet, web apps, online banking, online shopping, smartphones, mobile apps, app stores, Google search engine, SEO, social media, cloud computing, SaaS, audio and video streaming, machine learning, voice assistants, chatbots, NoSQL databases, and the majority of today's widely-used programming languages (JavaScript, C#, Ruby, Python, Go, Rust, Kotlin, Swift).

As a developer, you'll also need to continually learn new business domains and requirements, work with new people, and adapt to new processes, projects, and companies. In other words, you'll have to constantly reinvent yourself. If you don't enjoy learning - and don't become skilled and efficient at it - you'll struggle to have a successful software development career.

9. Learning is a skill that has to be honed like any other.

Though learning might appear natural, it's anything but. Our understanding of effective learning techniques has grown substantially over the past few decades and continues to evolve at a rapid pace. Sadly, schools in many countries lag behind, failing to teach students how to learn properly.

Start cultivating your learning skills as early in your career as possible. Approach it broadly: learn how to read faster, how to mindmap, and how to research and seek information efficiently. Also, understand how to accelerate learning in the context of software development: identify commonalities between different languages, learn through experimentation with the code, and utilize developer-specific platforms like GitHub or Stack Overflow. This will set you on the right path for your entire career, with the benefits compounding over time.

10. There's no better way to learn than on real-life projects.

Diving into small, "weekend" projects is a great way to quickly get the gist of new technologies and to get yourself hyped for further learning. However, these projects can't compare to the depth and thoroughness gained from building real, production stuff. Confronting user or business requirements, tackling real-life edge cases and bugs, and addressing scalability issues will push you in ways personal projects (where you can sidestep the toughest obstacles) simply can't.

I'm not saying you should avoid personal projects. They're fantastic for broadening your horizons. But if you want to truly master something, seek out opportunities to do it "for real".

11. No principle, pattern, or best practice is universally applicable.

Even the most widely accepted principles can't be applied unconditionally. If you don't deeply understand the theory, context, and edge cases - if you just blindly follow a cargo cult - you'll never become a true expert (nor truly impress a hiring manager during an interview).

But gaining such a deep understanding requires a distinct mindset.

Experiment with edge cases and boundaries. Dive as deep as possible, exploring where things break and how much you can stretch them. Look at the subject from various perspectives: through practice, mental experiments, blogging, teaching, presenting, and discussion. And finally, dig deep into the roots. Understand what the original authors had in mind, the problems they were solving, the context in which they operated, and how the principle later evolved and why.

12. Large, long-lasting projects will teach you more than greenfield ones.

Starting a project from scratch is tempting. You can experiment with different tech stacks, employ the latest best practices, and promise yourself to "write cleaner code this time."

But by working with a clean slate every time, you'll never experience the long-term impact of your decisions. You won't learn what code and architecture remain easy to work with after a few years. You'll never gain practical experience in critical skills like code archaeology, characterization tests, or refactoring. Most of today's best practices were discovered by working on long-lasting projects for years.

13. No time for learning is no excuse.

The most common excuse I hear from people for not growing professionally and not advancing their careers effectively is the lack of time outside of work hours. But you don't have to sacrifice your work-life balance. There's enough time at your job to learn almost everything you need to progress professionally. You just need to seek out and create suitable opportunities.

Challenge yourself to write code using new techniques. Shower your senior colleagues with questions (most people love sharing their knowledge). Review their code (even if it's not a formal requirement). Present at a conference. Volunteer to lead various initiatives. Volunteer to conduct research. Enlist the support of your manager (it's their job to help you learn and grow). Often, even explicitly requesting time for learning during work hours can be successful if you have a compelling pitch for how this time will be spent.

14. There are more ways to find mentors than you think.

Finding a mentor is crucial, especially in the early stages of your career. But where can you find a great mentor?

By rethinking what mentorship truly means at its core, you can bend the rules in your favor. Mentorship, in essence, is having someone more experienced review your work or provide customized advice. You can achieve this through a variety of channels.

Enlisting more experienced colleagues at work is the most obvious option. But you can also reach out to external consultants if your company employs any, even if they don't directly work with your team. By contributing to open-source projects, you can have your code reviewed by seasoned maintainers. You can get personalized advice from experienced thought leaders by commenting on their blogs. You can ask a question or post a poll on a discussion forum, Twitter, or LinkedIn. You can approach speakers at a conference. You can even directly reach out to people you admire – many of them will actually reply. You get the gist. Only your creativity is the limit.

On advancing your career

15. The only thing that really counts is the impact you make.

Businesses don't hire developers to look good on paper. Your knowledge, skills, and experience don't matter if they don't translate into tangible value - into a positive impact on the team, product, and company. And the bigger the magnitude of the impact, the more you'll be noticed and promoted, and the more the company will fight to not lose you.

Making a company-wide impact requires a very different mindset and a broader skillset than just becoming the best "coding ninja". And for many of us, it requires stepping way out of our comfort zone. But there's no other way to advance your career past the individual contributor stage.

16. You must understand also the business side of your job.

All businesses have similar needs: building competitive advantage, gaining new customers, optimizing their operational efficiency, sustainably growing in size, and adapting to changing market conditions. Software - and software development teams - are at the heart of all this.

If you want to be regarded as a true professional and make a company-wide impact, you must understand how businesses operate, what they need, and how software can best support these needs. It's you who should tell your company how to best utilize software to its advantage, not the other way round. Become an expert on the matter - a trusted technical advisor to your business - and your career will soar.

17. Marketing is key to success.

As a professional, you yourself become a product. And a product needs to be promoted. To get a new job, raise, or promotion, you must know how to sell yourself.

To be 100% clear: I'm not talking about false, shady marketing. But you need to make your accomplishments known. You have to "advertise" yourself: write an effective CV, create an eye-catching portfolio, make your manager aware of your contributions.

This doesn't only apply to directly advancing your career. Promoting your blog or open-source project, getting invited to speak at a conference, or even pitching your ideas to your teammates also requires a fair amount of marketing.

For many of us, this is far outside our comfort zone. However, if you change your mindset and develop decent marketing chops, they can give your career a significant boost.

18. First impressions matter a lot.

The first impression you make at a new company or team is critical. Your first few days and weeks can establish your reputation for the rest of your time there.

Open your first meaningful pull request within a day or two. Within the first few weeks, build rapport with your team and understand their work process, product, and business domain - and propose valuable improvements, delivering real business value without the "my way is better" attitude. You'll be instantly perceived as a true professional. Or even, if the improvements are substantial, as a natural leader who can influence the company's success.

That's why often neglected skills such as code archaeology, effective learning, communication, building rapport, understanding of software development processes, and being a business-oriented developer (along with a sprinkle of marketing) are so crucial.

19. Your current job is just a stepping stone.

Apart from the most junior roles, you get promoted or hired for your demonstrated skills and track record, not merely potential. To continuously advance your career, your current job must allow you to build the necessary skills, experience, and portfolio to secure your next position.

This should be your primary criterion when deciding to accept a job: not the immediate benefits of the current position, but what next job it'll allow you to build up to. Always think two steps ahead.

This applies also when deciding to change jobs. If you've exhausted all opportunities for building up towards the next position you aim for (either through learning, gaining experience, getting promoted, or making a lateral move) - that's the right moment to leave your current company.

20. A company is not a family.

Some companies, especially in the corporate world, treat their employees like cannon fodder. But there are also some truly exceptional companies out there, with a fantastic culture and strong camaraderie, that genuinely care about their crew (I've had the luck and pleasure of working in such an environment). When you work in a company like this, it's easy to become emotionally attached.

This is a mistake. And will inevitably lead to painful disillusionment and frustration.

A great company is, first and foremost, results-oriented - much like a sports team. Camaraderie and fun are important, but you also need to win matches. If you don't consistently perform at a given level, there's no place for you on the team. And if you aspire to be a true professional, you shouldn't shy away from expecting the same from your teammates.

Finally, if a company no longer needs your services or if you've found an even better opportunity to advance your career, it's not as if you're breaking an oath. Approach it with professionalism and respect, but maintain a level head and move on.

21. A healthy lifestyle is the best long-term career investment.

Many people don't perceive programming as physically demanding. However, sitting behind a desk for countless hours per week, with your eyes fixed on the screen and your shoulders hunched over the keyboard takes a toll on your body - especially when done for years and years. And this doesn't even take into account the mental strain of maintaining extended concentration and coping with stress.

You may disregard this when you're young, but please take care of your health in a holistic manner: take breaks at work, maintain a sustainable work schedule, set up an ergonomic desk, prioritize sleep, exercise regularly, maintain a healthy diet, spend time outdoors, recover mentally, and take your vacations. Otherwise, it will hit you hard later in your career, at a moment when you have the most momentum and potential, when you need to be at your best to capitalize on what you've built over the years, not plateau or burn out.

22. Task and time management is a critical career skill.

Learn task and time management as early in your career as possible. There's a vast body of knowledge on the topic and the skills are highly transferable, to software development and beyond. They will help you stay organized, be more productive, deliver on your promises, and never drop the ball - which is the surefire way to impress your manager.

Later in your career, these skills will provide you with a solid foundation for managing projects, overseeing complex initiatives, and leading teams.

Bottom line

Over the course of a 22-year professional career, you learn a lot of things, big and small (for an even more comprehensive take, check out my "Definitive Guide to Succeeding as a Professional Dev"). The 22 insights I've chosen are among those that have had the biggest impact on my career. And from my experience working with, leading, mentoring, and networking with other developers, I can say they work not only for me.

It's easy to focus primarily on the here-and-now coding skills, like the knowledge of your current tech stack - especially at the early stage of your career. To some extent, this is fine. You'll never become a successful developer without the fundamentals in place. However, the sooner you start diving into deeper, more "meta" topics like career development, effective learning, and timeless truths about programming, the faster your career will advance - and the more mature and in-demand developer you'll become.

📣 The fifth chapter of my "Definitive Guide to Succeeding as a Professional Dev" is now out!

It dives deep into how career ladders work across the industry and why it's critical to understand it - even if your company doesn't have a multi-tiered career ladder (or any at all).

📖 Read it on HERE

Or, if you need a refresher, check the full table of contents.

PS: If you find the guide helpful, don't hesitate to share it!

🫶

Wojciech

In a nutshell

• Estimating (and resulting predictability) offers numerous benefits but also comes with significant drawbacks.

• Many of these benefits can also be achieved through other means, without precise estimating.

• Moreover, estimates are just half of the story. The second pillar of achieving predictability is reducing variability.

• It's also vital to be deliberate about what level of predictability you actually need.

One of the most polarizing topics in software development

Estimates are a contentious subject. Managers and businesses want them, while developers hate them. The debate over whether and how to estimate is almost as old as programming itself.

When people ask me about estimation, they either come already strongly biased towards always or never estimating, or they focus too much on the minor details. The complete picture, however, is far more nuanced and highly context-dependent.

To understand whether, when, and how you should estimate, you need to start with one fundamental question:

A million-dollar question: Why do we estimate?

The short answer: predictability.

A.k.a.: How much will it cost? When will it be ready?

But why do we need to know this? For example, for:

• Prioritization. To compare the size/cost versus expected value/impact of a feature, to decide if it's worth pursuing.

• Budgeting, resource allocation. To understand how many teams should focus on a project, for how long, and how much will it cost us.

• Synchronizing teams on bigger projects. To ensure smooth handovers and avoid blockages when teams depend on each other.

• Synchronizing releases of multiple related products. For example, launching a new iPhone alongside new versions of iOS, XCode IDE, and the Swift language.

• Planning marketing campaigns, press releases, or public demos. To prepare and announce them enough in advance.

• Pricing projects for external customers. To be able to agree on the cost and delivery date upfront, before the project starts.

• Meeting hard deadlines. While most deadlines are self-imposed (which is a topic worthy of its own discussion) some are externally mandated, such as legislative or tax-related ones.

High predictability also brings two massive bonuses:

• Building Trust. Delivering on your promises is a great way to earn trust from business, stakeholders, customers, and management.

• Boosting Team Morale. Consistently delivering on your promises also builds self-confidence and morale.

Whoa. Sounds great. But it's not always so rosy...

The drawbacks of estimating

While predictability brings many benefits, it comes with a cost—often steep. For example:

• Estimating takes time. Often a lot. And releasing earlier usually brings more value than releasing on a precise date.

• It creates pressure. This can negatively affect quality, create stress, and burn the team out.

• There's a fundamental tension between predictability and agility. Predicting something upfront is, by definition, at odds with discovery, experimentation, and iterative approaches.

• It kills creativity and innovation. The clarity and control required for accurate predictions don't align with the randomness of creative freedom.

• It creates false confidence. Believing in a precise deadline, when in reality, your estimate is grossly off, can put your business at risk.

• It can destroy trust and morale. Estimating correctly every time is hard. And failing to meet estimates damages trust and morale pretty fast - much more than making no promises at all.

Given so many drawbacks, is there another way to achieve similar benefits?

Indeed, there often is.

Estimation alternatives

Many of our goals can be achieved without precise estimates. For example:

• Prioritization. Often, a rough, gut-feel estimate suffices to determine if something is worth pursuing. Especially considering that estimating value/impact is even less precise.

• Budgeting, pricing, resource management. These can be managed with more agile approaches like "time & materials" or a fixed budget, supported by transparency and frequent feedback.

• Synchronizing teams. Cross-functional teams, well-defined areas of responsibility, clean architecture, and eliminating waterfall stages allow teams to work more independently, without tight synchronization.

• Upfront delivery dates and marketing events. Fuzzier promises ("next quarter") are often sufficient. And when you need to commit to a fixed date, a variable scope approach, implementing the most important "vertical slices" first, and gradual releases behind feature flags can give you enough flexibility.

• Trust and morale. Frequent high-quality releases, delivering value early and often, de-risking through mockups and prototypes, high transparency, and good communication and expectations management, can build trust even more effectively than meeting deadlines.

• Hard deadlines and synchronizing releases. This one is harder, but even here, a variable scope and fixed budget approach, with a sufficiently large buffer, can mitigate the need for precise estimates.

As you can see, precise estimation can be often avoided. Moreover, predictability isn't just about estimates.

Reducing variability: the second pillar of predictability

The more variable something is, the harder it is to predict (duh!).

Imagine a car compared to a metro train.

A car must wait at traffic lights, can get stuck in a traffic jam, and may be delayed due to bad weather conditions. All of which are difficult to foresee and estimate.

A metro train, on the other hand, doesn't stop at the crossroads or get stuck in traffic. And since it runs in a tunnel, it's not affected by the weather. In effect, you can predict its arrival down to minutes, if not seconds.

If there are no variable elements, you don't have to estimate (guess). Instead, you can simply measure and rely on your measurements to be repeatable.

Plus, repeatable measurements not only eliminate the need for estimation but also open up a whole new world of benefits. For example, the ability to provide Service Level Agreements (SLAs) to your clients.

What's more, reducing variability doesn't create tension with agility - it actually facilitates it.

So, if low variability is so desirable, how can we achieve it?

How to reduce variability

Variability can be reduced by making processes more consistent and by eliminating surprises (or at least anticipating them and minimizing their impact).

A few examples of how this can be achieved:

• De-risking and risk management. Through prototyping, contingency plans, pre-mortems, and tackling the most difficult or unclear things first.

• Minimizing surprises in the code. Through a clean code base, consistent coding conventions, automation, design systems, and component libraries.

• Frequent integration and deployments. To prevent surprises from accumulating and compounding over an extended period.

• Solid QA process. Ensuring a low and predictable bug rate and tech support response times.

• Timeboxing. Things done in fixed-size chunks are more repeatable and easier to predict and statistically analyze.

• Splitting big projects. The smaller the tasks, the less room there is for variability, the easier they are to estimate, and there are bigger batches of them - which makes statistical analysis more reliable and minimizes the impact of outliers.

However, before you start applying these strategies, ask yourself how much predictability you actually need.

How much predictability is enough?

Predictability has many benefits. But more predictability isn't always better.

It doesn't make sense to plan, estimate, and de-risk your daily commute to work as meticulously as a multi-leg flight for a once-in-a-lifetime business opportunity.

To avoid wasting too much effort, you should be conscious of these factors:

• Do you need short- or long-term estimates? Are you more interested in what you will deliver this sprint, when your current project will end, or what your roadmap for the next 6 months will look like?

• What accuracy and precision are required? Do you need to know the exact day of the project delivery? Or will a week, month, or even a quarter suffice? Is it acceptable to miss this deadline by a day? A week? A month?

• How narrow your "cone of uncertainty" has to be? Do you need to know the exact release date before the project even starts, halfway through, or just a few weeks before it ends?

There are no universal answers to these questions. They are heavily context-dependent and should be answered on a case-by-case basis.

So, should you estimate (in a given case)?

There's no universal "always/never" answer. You need to consider:

• What's your primary reason for estimating in this particular case? What (and whose) needs are you trying to address? Can they be addressed more efficiently in a different way?

• What precision and accuracy do you need? Why? Are you even able to meet them? How hard this particular project is to estimate?

• What will happen if you don't estimate? What will happen if you estimate wrong? Which one has worse consequences?

• What will you gain if your estimates are on point? What will you lose? Is predictability or agility more important in this particular case? Why?

Bottom line

The definitive answer to "Should you estimate?" is that there's no universal answer.

It's highly contextual and depends on your particular needs and capabilities. Estimation has both benefits and drawbacks, and can be often replaced with alternative approaches. It's also closely linked to variability, with its own slew of techniques to improve it. Plus, it requires a different approach depending on the scope, precision, accuracy, and how far in advance you need it.

You must also consider the bigger picture: Do you need estimates and predictability frequently enough to invest in your capability to do them well (even if you don't necessarily need them for this particular project)? Or will you gain more from investing in being agile and innovative, even if you fail to provide necessary estimates from time to time?

Nothing will accelerate your growth quite like an experienced mentor. However, finding one can be challenging, and their availability is often limited.

On the other hand, AI agents like ChatGPT are available 24/7 and seem to be quite knowledgeable as well. Could such an agent serve as a reasonable substitute for a real, human mentor?

What I'm particularly interested in is more "meta" advice - the small tips and tricks, acquired only through extensive experience, that will help you grow and mature as a developer - not merely generating or explaining code.

As someone with over 20 years of experience, who has mentored several junior developers, I'm curious how sound, comprehensive, and actionable for a beginner such ChatGPT's advice would be.

Let's take it for a quick test drive!

TL;DR.

If you're curious about the quality of ChatGPT's advice but don't want to go through the entire discussion and my detailed step-by-step commentary, feel free to jump straight to the last section.

A short legend.

💬 My prompts.

🤖 ChatGPT answers.

🤔 My thoughts/comments.

The setup.

💬 Act as a seasoned, professional software developer with over 10 years of experience. Imagine that you are mentoring a younger, junior colleague, with no more than 2-3 years of experience. I'll be asking you different questions related to programming and software development career. I'll be asking them as this younger dev. Answer them in a way that will be most helpful for me to become a better developer and grow professionally.

🤖 Sure, I'm here to help you! Feel free to ask any questions you have about programming or your software development career, and I'll do my best to guide you based on my experience.

🤔 So far, so good. Let's get started!

The "Million $" question: 10 lifehacks to become a better developer.

💬 Please share 10 lifehacks that are quick and easy to implement and will immediately help me become a better developer.

🤖 Of course! Here are 10 lifehacks that you can quickly implement to improve your skills as a developer:

1. Use keyboard shortcuts: Learn and use IDE or editor-specific keyboard shortcuts to navigate and manipulate code faster. It will save you time and increase your productivity.

2. Follow the Pomodoro Technique: Break your work into small, manageable intervals (usually 25 minutes) followed by a short break. This technique can help you stay focused and maintain a consistent work rhythm.

3. Master version control: Get comfortable with Git or another version control system. This will help you track changes in your code, collaborate with others, and revert to previous versions when needed.

4. Automate repetitive tasks: Use scripts or tools to automate mundane tasks like code formatting, file renaming, or project scaffolding. This will save you time and reduce the chances of human error.

5. Read and write clean code: Adopt a clean coding style that's easy to read and understand. Follow best practices for naming conventions, indentation, and code structure. This will make your code more maintainable and reduce the time spent on debugging.

6. Comment your code: Write meaningful comments to explain the purpose and functionality of your code. This will make it easier for others to understand your code and for you to recall your thought process when revisiting the code later.

7. Seek code reviews: Ask your colleagues or mentors to review your code regularly. This will help you identify areas for improvement and learn from their expertise.

8. Stay curious: Constantly explore new languages, frameworks, and tools. This will help you stay up-to-date with the latest industry trends and broaden your skillset.

9. Break problems into smaller pieces: When faced with a complex problem, break it down into smaller, more manageable tasks. This will help you maintain focus and prevent you from getting overwhelmed.

10. Take care of yourself: Prioritize your physical and mental well-being. Exercise regularly, get enough sleep, and take breaks when needed. A healthy mind and body will help you be more productive and focused in your work.

Remember, becoming a better developer is an ongoing process, and it takes time and dedication. But by implementing these lifehacks, you can accelerate your growth and continuously improve your skills.

🤔 The list seems mostly solid, though somewhat random and not particularly groundbreaking. However, I did ask ChatGPT for beginner advice, so the relatively obvious answers are understandable.

Some of these tips don't seem so quick and easy to implement (which was part of my prompt). A few others are a bit vague and require further explanation – but since ChatGPT is designed to be used iteratively, digging deeper and deeper with follow-up questions, I guess that's fine. There are a couple of points I don't fully agree with, but I view them more as a matter of opinion rather than being incorrect. Overall, not bad!

Let's dive a bit deeper into each suggestion:

1. Use keyboard shortcuts: Solid advice. Fast and easy to implement, and it will undoubtedly boost your productivity. One thing that surprises me is why only simple keyboard shortcuts? Utilizing more advanced features like code intelligence, snippets, autoformatters, code generators, and AI assistants like GitHub Copilot (or ChatGPT itself, duh) would be equally easy to start using and provide a much bigger boost.

2. Follow the Pomodoro Technique: Good advice. You should definitely try it. If you have never heard of Pomodoro before, you may have to google it or ask ChatGPT a follow-up question, but it's otherwise pretty straightforward and self-explanatory.

3. Master version control: Good advice, but definitely not a lifehack. Even the word "master" clearly shows that it's not a quick and easy fix. I'd also argue that version control is an integral part of your primary tech stack, similar to your programming language, main framework, or database, rather than a "hack" to improve your productivity. But otherwise, the advice is correct.

4. Automate repetitive tasks: Solid advice, but again, it needs further exploration. It's too high-level to implement immediately.

5. Read and write clean code: Reading a lot of clean code (or code in general) is fantastic advice – and easy to implement. The only tricky part is how to know, as a beginner, which code is clean and where to find it. This again requires deeper inquiry. Writing clean code, however, is a completely different matter. It's part of a lifelong mastery of your craft, and entire books are written on the topic. You should absolutely study it, but just like with mastering version control, it's very far from a lifehack.

6. Comment your code: This is the first tip that I find debatable (though, as I said earlier, not because it's obviously wrong but because of personal preferences). There are two stances regarding comments: commenting heavily vs making code so self-explanatory that you don't need comments (unless you need to explain the business purpose behind your code). I'm strongly in the second camp, so ChatGPT's very authoritative "write comments" doesn't resonate with me. On the other hand, it also says to write meaningful comments and to explain the purpose of your code, which I very much agree with. But it also says to explain the functionality of your code, which I consider a bad practice and a waste of time. So, I have mixed feelings on this one.

7. Seek code reviews: This advice is as solid and easily applicable as it can get. You should absolutely seek code reviews as much as possible, especially as a beginner.

8. Stay curious: This is the second piece of advice that I find somewhat arguable. Exploring new languages, frameworks, and tools is overall good advice (though I'd argue about "constantly" - it smells like buzzword-driven development), but it may not be the best strategy for a beginner with only a year or two of experience. As a junior, you should focus more on building a solid foundation of best practices and principles and learning them in-depth, which is easier when you focus on mastering a single stack for a while. But, frankly, I'm nitpicking here, and I wouldn't call this piece of advice wrong.

9. Break problems into smaller pieces: Solid advice, but again, it's too high-level. Breaking down problems effectively is not trivial. To actually implement this in practice, some further drill-down would be required.

10. Take care of yourself: Very good and applicable advice. It's actually nice that ChatGPT included advice like this, which isn't directly related to hard tech skills.

Alright, we went through all the tips. Not bad, not bad at all. However, not all of them are immediately applicable. Let's drill down into a few to see how close we can get to the core

Keyboard shortcuts - digging deeper.

💬 Let's dig deeper into the "Use keyboard shortcuts" tip. Can you elaborate a bit if I should learn all possible shortcuts, or if there are any particular categories of shortcuts I should focus on?

🤖 Certainly! When it comes to keyboard shortcuts, the key is to focus on learning the ones that will have the most significant impact on your productivity and efficiency. You don't need to learn every single shortcut available, but rather prioritize the ones that will save you the most time and help streamline your workflow.

Here are some categories of keyboard shortcuts to focus on:

1. Navigation shortcuts: These shortcuts help you quickly navigate through your code, jump between files or tabs, and find specific symbols or instances of a keyword. Examples include "Go to Definition," "Go to Line," and "Find All References."

2. Editing shortcuts: These shortcuts assist you in manipulating code by cutting, copying, pasting, and formatting text. Examples include "Duplicate Line," "Move Line Up/Down," and "Toggle Comment."

3. Refactoring shortcuts: Refactoring is an essential part of maintaining clean and efficient code. Shortcuts that help you refactor code quickly can save you a lot of time. Examples include "Rename Symbol," "Extract Method," and "Change Signature."

4. Debugging shortcuts: Debugging is a crucial part of the development process. Shortcuts that help you manage breakpoints, step through code, and inspect variables can streamline your debugging sessions. Examples include "Toggle Breakpoint," "Step Over," and "Step Into."

5. IDE-specific shortcuts: Your IDE or code editor might have unique features or tools that can be accessed through shortcuts. Familiarize yourself with these shortcuts to make the most of your chosen development environment.

Keep in mind that the actual key combinations for these shortcuts may vary depending on the IDE or code editor you're using. Refer to your editor's documentation or settings to discover and customize these shortcuts to your preference.

When learning shortcuts, start by focusing on a few at a time. As you become more comfortable with them, gradually incorporate more shortcuts into your daily workflow. Over time, using these shortcuts will become second nature, and you'll notice a significant improvement in your productivity and efficiency.

🤔 That's a great categorization! I'm impressed. I also like the concrete examples for each category. This level of advice is already actionable – you can easily look for "Navigation shortcuts" or "Go to Definition" in your IDE's documentation. Moreover, the categories are well-chosen. They are truly the ones that will give your productivity a significant boost.

There's just one thing I'm still missing: the more substantial productivity boosters, like auto-completion or code snippets. I don't want to ask about them explicitly, as I'm pretending not to know they exist. However, let's bend the rules a bit:

💬 You said that I should learn shortcuts "to navigate and manipulate code faster", that "the key is to focus on learning the ones that will have the most significant impact on your productivity and efficiency", and to "prioritize the ones that will save you the most time and help streamline your workflow". Are there any other tools or IDE features, apart from keyboard shortcuts, that could help me achieve these goals?

🤖 Absolutely! Apart from keyboard shortcuts, there are many other tools and IDE features that can help boost your productivity and efficiency. Here are some of them:

1. Code snippets and templates: Many IDEs and editors support code snippets or templates that can generate commonly used code structures or boilerplate code with just a few keystrokes. These can save you time and help maintain consistency in your code.

2. Auto-completion and IntelliSense: Modern IDEs and code editors often provide intelligent code completion, which suggests completions for variables, methods, or keywords based on the current context. This can speed up your coding process and reduce the chance of typos or syntax errors.

3. Integrated debugging: Debugging tools integrated into your IDE allow you to set breakpoints, step through your code, and inspect variables without leaving your development environment. This seamless debugging experience can help you find and fix issues more efficiently.

4. Version control integration: Many IDEs offer built-in support for version control systems like Git. This integration can simplify common version control tasks, like committing changes, creating branches, and resolving conflicts, all within your IDE.

5. Code analysis and linting: Real-time code analysis and linting tools can help you identify potential issues, such as syntax errors, unused variables, or code style violations, as you write your code. This can save you time on debugging and ensure your code adheres to best practices.

6. Refactoring tools: Some IDEs have built-in tools that can automatically refactor your code, such as extracting methods, renaming variables, or changing method signatures. These tools can help you maintain clean and efficient code without manual effort.

7. Task and project management: Many IDEs and editors have features that allow you to manage tasks, create to-do lists, and track progress within your projects. This can help you stay organized and prioritize your work more effectively.

8. Customization: Most IDEs and editors offer a high level of customization, including themes, plugins, and configuration options. Tailoring your development environment to your preferences can help you work more comfortably and efficiently.

9. Integrated terminal: Having an integrated terminal within your IDE can save you time by allowing you to run commands, build your project, or interact with version control without switching between windows.

These tools and features can significantly improve your coding experience, making you more efficient and productive. Take the time to explore your IDE or code editor's capabilities, and don't hesitate to try new tools or plugins that can enhance your workflow.

🤔 Now we're talking! The list is not entirely exhaustive (for example, it misses code auto-formatters, and it surprisingly still misses AI assistants – isn't ChatGPT aware of its own capabilities? Or is it just too humble?) but it's solid and broad enough to be genuinely useful for a beginner dev. Plus, now that you're aware of the richness of modern developer tools, you can gradually dig even deeper.

Version control - getting down to more actionable, bite-sized tips.

💬 One of the tips you gave me was "Master version control". But is it really a quick and easy lifehack? It seems to me like a long process to fully master version control. Are there any version control-related quick tips, that could be implemented right away?

🤖 You're correct that mastering version control can be a longer process, but there are some quick tips and best practices you can implement right away to make more effective use of version control systems like Git. Here are a few:

1. Commit frequently and in small units: Make small, focused commits that contain a single, logical change. This makes it easier to understand the history of the project, locate issues, and revert changes if necessary.

2. Write descriptive commit messages: When you commit changes, write clear and concise commit messages that describe the changes and their purpose. This helps you and your team understand the project history and makes it easier to find specific changes later.

3. Use branches: Create branches for new features, bug fixes, or experiments. This keeps your main branch stable and allows you to work on multiple tasks in parallel without affecting the main codebase.

4. Merge regularly: Merge changes from the main branch into your feature branches regularly to keep them up-to-date and minimize merge conflicts when it's time to integrate your changes.

5. Pull before you push: Before pushing your changes to the remote repository, always pull the latest changes from the remote to ensure your local repository is up-to-date. This can help prevent conflicts and ensure a smoother collaboration experience.

6. Embrace .gitignore: Use a .gitignore file to exclude files that don't need to be tracked, like temporary files, build artifacts, or IDE-specific files. This keeps your repository clean and focused on the essential code.

These quick tips can help you make more effective use of version control systems and streamline your workflow. While they may not make you a version control master overnight, they can serve as a solid foundation for you to build upon as you continue to learn and refine your skills.

🤔 Pretty slick. Although these tips won't lead you to full version control mastery, they are now more actionable – and overall, they're pretty decent, considering it's advice for beginners.

Some points remain a bit vague, for example, "Use branches". Version control branching strategies is a broad, complex topic, and this particular point isn't very actionable without further exploration. However, it's a single outlier and at least provides a clear starting point for more in-depth research.

Overall, not bad!

Reading clean code - cutting through ambiguity.

💬 You gave me a tip to "Read clean code". But how will I know, as a beginner, which code is clean? How to recognize it? And where to find such code to read?

🤖 As a beginner, it might be challenging to recognize clean code at first glance. However, with practice and exposure to well-written code, you'll start to develop an understanding of what constitutes clean code. Here are some general guidelines and characteristics of clean code:

1. Readability: Clean code is easy to read and understand. It has a clear structure, meaningful variable and function names, and proper indentation. It also follows consistent naming conventions and style guidelines.

2. Modularity: Clean code is organized into small, focused functions or methods that perform a single task. Each module should have a single responsibility, and the code should be divided into logical components.

3. Maintainability: Clean code is easy to modify, extend, and refactor. It avoids duplicating code (DRY principle) and follows best practices to minimize the chances of introducing bugs when changes are made.

4. Documentation and comments: Clean code is well-documented with comments that explain the purpose and functionality of the code. Comments should be concise and only provide information that is not immediately apparent from reading the code itself.

5. Efficiency: Clean code is efficient in terms of performance and resource usage. It avoids unnecessary complexity, and the algorithms and data structures used are well-suited for the problem at hand.

To find clean code to read and learn from, consider the following sources:

1. Popular open-source projects: Many popular open-source projects on platforms like GitHub have high-quality code that has been reviewed and refined by multiple contributors. Explore projects in the language or framework you're working with to find examples of clean code.

2. Coding best practices: Look for articles, books, or courses on coding best practices for the programming language you're working with. These resources often provide examples of clean code and guidelines on how to write it.

3. Code reviews: Participate in code reviews within your team or seek feedback from experienced developers or mentors. Observing their feedback and suggestions can help you learn to recognize clean code and improve your own coding style.

4. Coding challenges: Websites like LeetCode, HackerRank, or Codewars offer coding challenges along with solutions submitted by other users. Reviewing these solutions can help you learn different approaches to problem-solving and expose you to clean code examples.

Remember, recognizing and writing clean code is a skill that develops over time. As you read and write more code, you'll become more adept at identifying clean code and adopting best practices in your own work.

🤔 This time, the result is meh at best.

The first part of the answer essentially states that you can recognize clean code by the fact that it adheres to very high-level and vague principles of being clean code (some of which, like comments and efficiency, are even debatable – for instance, does code really need to be efficient to be clean and readable?).

The second part is also hit-or-miss. Participating in code reviews is good advice (although it could be more emphasized that you should not only have your code reviewed but also do as many reviews as you can yourself, to learn from the code of more senior developers). Reading books and articles on coding best practices is sound advice but rather obvious, not adding much value. Learning from open-source projects and coding challenge websites is potentially fantastic advice, but these sources often contain bad code as well, and it still doesn't solve the conundrum of how a beginner can recognize which is which.

Let's try to dig a bit deeper:

💬 You said that to find clean code to read and learn from I can look at popular open-source projects, as many of them have high-quality code. But many of open-source projects have low-quality code as well. How can I recognize which open-source project is high-quality and which is not?

🤖 You're right that not all open-source projects have high-quality code. To identify high-quality open-source projects, you can consider the following factors:

1. Popularity: Projects with a large number of stars, forks, or watchers on platforms like GitHub usually indicate that the project is well-regarded by the community. While popularity isn't a guarantee of code quality, it can be a helpful indicator.

2. Active maintainers and contributors: High-quality projects tend to have active maintainers and a diverse group of contributors. Look for projects with a history of regular commits, updates, and bug fixes. A healthy number of contributors and an active community can be a sign that the codebase is continuously improved and refined.

3. Clear documentation: Well-documented projects are often a sign of a well-maintained and high-quality codebase. Look for projects with comprehensive README files, API documentation, and usage guides.

4. Code reviews and discussions: Check the project's pull requests and issue discussions. A healthy project will have thorough code reviews, constructive feedback, and active discussions around improvements and bug fixes.

5. Adherence to coding standards: High-quality projects usually follow coding standards and best practices for the programming language or framework they use. Look for consistent formatting, naming conventions, and code organization.

6. Automated testing: Projects with a robust suite of automated tests indicate that the maintainers care about code quality and ensuring the software works as expected. Look for projects with a high test coverage and a continuous integration (CI) pipeline that runs tests on every commit or pull request.

7. Dependencies and licensing: High-quality projects should have a clear list of dependencies, along with their corresponding licenses. This shows that the maintainers pay attention to the project's legal and operational aspects.

To begin your search for high-quality open-source projects, you can explore curated lists or collections, like Awesome Lists on GitHub, which aggregate popular and well-regarded projects in various domains. You can also check out projects maintained by reputable organizations or developers who are well-known in the industry.

Remember that even high-quality projects may have areas that could be improved. As you gain more experience, you'll develop a better understanding of clean code and be better equipped to assess the quality of various open-source projects.

🤔 This answer is decent once again. While factors like project popularity or good documentation don't necessarily guarantee clean code, all of them combined are a decent proxy – probably as good as you can get, since there are never hard guarantees. And the advice to look at curated lists, although they're more of an indicator of popularity rather than necessarily quality, provides a reasonable starting point. It's not exhaustive, as GitHub search, for example, is also a great way to find popular and active open-source projects. But considering that recognizing clean code is a very subjective and difficult topic, this answer is quite ok. We could try to dig even deeper - but I need to keep the length of this post under control...

Commenting your code - clarifying the questionable aspects.

💬 One of the lifehacks you gave me was to write meaningful comments to explain the purpose and functionality of my code. Can you elaborate on this? What comments do you consider meaningful? Should I always write comments for all of my code? Is there any good heuristic on when and how to write comments?

🤖 Writing meaningful comments is an important aspect of writing clean and maintainable code. Meaningful comments should provide additional insight and context that's not immediately apparent from reading the code itself. Here are some guidelines on when and how to write comments:

1. Explain complex or non-obvious code: If a piece of code is complex or might be difficult to understand for someone unfamiliar with the project, a comment can help explain the reasoning behind the implementation or provide a high-level overview of the algorithm.

2. Document assumptions and limitations: If your code relies on specific assumptions or has limitations, it's important to document them in comments. This helps prevent future issues or misunderstandings when someone else (or even you) modifies the code later.

3. Clarify the purpose of functions and classes: While function and class names should be descriptive, a brief comment can provide additional context on the purpose and expected behavior of a function or class.

4. Explain workarounds or hacks: If you had to implement a workaround or hack to address a specific issue or limitation, document the reasoning and any potential side effects in a comment. This helps future maintainers understand the purpose of the workaround and consider potential improvements.

5. Reference external resources: If your code is based on a specific resource, like a research paper, algorithm, or third-party library, include a comment with a reference to that resource. This helps provide context and background information for others working on the project.

Here are some tips on how to write effective comments:

1. Be concise: Comments should be short and to the point. Avoid writing long paragraphs or repeating information that's already clear from the code.

2. Keep comments up-to-date: Ensure that your comments stay relevant as your code evolves. Update comments when you modify the code, so they accurately reflect the current state of the code.

3. Avoid stating the obvious: Refrain from writing comments that simply restate what the code does. Focus on providing context, rationale, or explanations that aren't immediately obvious from the code itself.

You don't need to write comments for every single line or block of code. Instead, focus on commenting where it adds value and helps improve the understanding of the code. Keep in mind that well-written code should be mostly self-explanatory, so prioritize writing clear and expressive code, using comments to supplement when necessary.

🤔 This is a really good answer. While the initial tip was ambiguous and left room for interpretation that could potentially lead to over-commenting, this elaboration clarifies it well and is 100% on point. That's exactly how I'd advise approaching writing comments.

Conclusion.

There were a few small missteps here and there, but overall the results are surprisingly good.

Some answers were too obvious, some were a matter of opinion, but none of them were plainly wrong and many of them were really good and actionable. I also liked the breadth and variety of advice - it even included a point about taking care of your health!

The initial answers are shallow - they don't bring much value without going at least a few levels deeper through follow-up questions. But if you get used to this flow, it goes quite smoothly. You don't get overwhelmed with loads of information upfront but instead can explore gradually, diving deeper into only the topics you are interested in or don't understand. I'd even say that it resembles working with a real, human mentor more than, for example, reading a book or watching a course.

There's a bit more burden on you when working with ChatGPT compared to a real human mentor. A human can pick up on more cues from your tone of voice, facial expressions, and body language, and can steer the discussion more proactively in response to your behavior. When working with ChatGPT, however, the only cues it can pick up are your direct questions – so the quality of the experience depends solely on your ability to formulate clear questions, not on your mentor's experience or emotional intelligence. That being said, learning how to ask proper questions isn't too difficult, and if you do, you can still get plenty of value from your interaction.

For a beginner, the trickier part may be figuring out what exactly to ask about in order to move from shallow to deeper answers. If you don't have in-depth expertise in a given area, it's often far from obvious. However, this can be mitigated by learning to ask more general "drill-down" questions, like "Why have you chosen this answer?", "Can you elaborate further?", "Is this answer really the best one?", "Is this the only good answer?", "What are the pros and cons?", "What would be the alternatives?", "Are there more similar techniques?", and so on. Getting good at asking questions like these will also benefit you in your day-to-day job: when clarifying requirements, brainstorming with your teammates, or even when working with a real human mentor – so it's a worthwhile training in itself.

To sum it up, from what I can observe from such a limited test, I'd certainly recommend it.

It's not a complete substitute for a real human mentor, but if you don't have access to one, you should definitely try ChatGPT. And even if you do have a mentor, it's still worth leveraging both, as ChatGPT is much more readily available. You can start with ChatGPT (and use it more frequently) and then ask your real mentor to evaluate its answers, expand on them, or delve deeper into trickier areas while sticking to ChatGPT for the more straightforward cases.

It may also be beneficial to start with a high-level overview of what there is to learn in a given area, to understand the overall lay of the land - and then use ChatGPT to dig deeper into selected topics. There are many good resources that provide such an overview, like roadmap.sh or the guide that I'm writing.

In a nutshell

• Software is the main engine of revenue and growth for most companies. It is also done at a scale that makes it impossible to micromanage everything top-down.

• Thus, being just a code monkey won't cut it. Professional developers are expected to contribute to the company's overall success: provide a competitive advantage, fuel sustainable growth, ensure adaptability to changing market conditions.

• In this article, I'll take a deeper look at what makes companies successful and what skills you need as a developer to help achieve this success.

The evolution of software development (too critical to neglect, too complex to micromanage)

As Marc Andreessen famously said in 2011, software is eating the world.

Modern companies depend on software as never before. Even if they don't sell it directly as a product, software is still fundamental to driving their operations and growth. It's critical for their customers, employees, suppliers, and partners. It's the engine that runs the business - and the network that connects it with other businesses. It's the cornerstone of the company's success.

At the same time, the software got bigger. Much bigger. And the software development process got incomparably more complex: Huge teams. The whole portfolios of products. A vast network of interconnected APIs. Complex distributed architectures. Tens or even hundreds of external vendors. Constant progress at a crazy pace. Cutthroat competition and continuously changing user tastes. No manager, analyst, or architect is able to micromanage it all. The responsibility has to be distributed.

And this completely changes the game for us, developers.

Raising the bar for software developers (the new definition of a "code monkey")

A "code monkey" isn't a new term. Developers who just churn out code without looking at a broader context were frowned upon from the early days of programming. However, for a long time, this "broader context" just meant more conceptual work like code design or architecture. But it doesn't cut it anymore.

Nowadays, I'd define a code monkey differently: A code monkey is a developer who contributes only to building software, not to the holistic company's success.

Yes, this is why we, developers, are hired. To generate business value. To make companies grow and thrive. And this requires a different mindset and a different, broader set of skills.

But, first of all, you need to understand what makes companies successful - and where you fit into this puzzle.

The 4 key elements of the company's success (and how you can influence them as a dev)

The recipe for a company's success, while insanely hard to achieve, is, at its core, very simple.

First of all, a company needs to have a competitive advantage. It needs to be better than the competition (or at least differentiate itself enough) in one or more of these aspects: have a better product, be more innovative technologically, build new products faster, or be cheaper.

Then, when the company becomes successful, it naturally starts to grow. Rapid growth is hard to manage and - if the company is not skillful at it - can destroy its competitive advantage.

Next, to be truly successful, a company needs to sustain its competitive advantage over time. It needs to cut enough corners to win now - but not as many as to die the "death of a thousand cuts" later.

Finally, the world never stands still. To not lose its edge, a company needs to continuously evolve to adapt to the ever-changing user tastes, competition, and market.

Let's now take a look at these 4 ingredients in more detail.

Competitive advantage: Product

Building a better product is the most obvious competitive advantage. If users like and buy your product more than the other ones - you win. But what convinces them to do so?

It all boils down to two things: addressing users' needs and providing a great user experience.

So how you, as a developer, can influence these two areas?

• Improve your communication skills to collaborate effectively across functions, with designers, product managers, business stakeholders, and users. Especially, learn how to talk to non-programmers (explain technical concepts simply, abstain from jargon, be patient with less tech-savvy people, etc.).

• Learn the principles of experimentally discovering what users want: Agile, empiricism, iterative development, Lean Startup, product discovery.

• Get good at working in short iterations, building small MVPs (Minimal Viable Products), and rapid prototyping, to help product managers validate ideas faster.

• Understand how to rapidly test ideas without coding (fake door, Wizard of Oz, concierge, and similar techniques).

• Learn the fundamentals of the product metrics and get a good overview of various analytics approaches (page views tracking, event tracking, backend API requests tracking, heatmaps, etc.) and the analytics tooling ecosystem (Google Analytics, Pendo, Segment, HotJar, and so on).

• Don't push to always solve everything by writing new code. Get comfortable with solving problems through 3rd party integrations and no-code solutions.

• Learn the basics of usability and user experience (UX).

Competitive advantage: Technology

Developing more advanced technology is another competitive edge. This is a bit different from just creating a better product. Of course, you still need to solve real user problems, but your winning strategy is not making the product more fine-tuned and polished but making it capable of things no one else is capable of.

Imagine invoicing software. Making re-typing the content of paper invoices into the system by hand smoother, faster, and done in fewer steps is one thing but being able to import them automatically, without typing anything, through advanced text recognition and extraction would be at a completely different level, even if the interface is not that polished.

It doesn't have to happen at such a dramatic scale, though. Even small technical advancements can provide a competitive edge: make processes faster for the user, reduce their costs, make the product more capable.

But how a regular developer can help their company gain a technological advantage?

• Get a good overview of the existing ecosystem, both open source and commercial: languages, frameworks, libraries, cloud and SaaS platforms, APIs, tooling, and so on. Often the advanced capability you need is already out there, available as a 3rd party library or service - you just need to know it exists and understand how it can be used.

• Stay up to date with the newest trends and technological advancements (especially the upcoming, not yet widely adopted ones) to be able to notice and exploit opportunities to gain a technical advantage.

• Learn about your company's business domain, its product, and its competition, so you can propose the most innovative technical solutions to the business problem at hand.

• Stay up to date with what's happening also outside your company's domain. Track what other popular apps are doing - what's the current state of the art in the broader industry - and "steal" and adapt the best ideas to your company's needs.

• Experiment with new stuff regularly (just enough to get a good grasp of what it is about and be able to quickly learn more about it when needed).

• Get good at researching, quickly learning new tech when needed, and doing small prototypes and proofs-of-concept.

Competitive advantage: Process

The next way of gaining a competitive advantage is through better processes. In other words, the ability to build stuff faster than the competition without sacrificing quality. In the short term, it will give your company the first-to-market advantage. In the long term, it will allow you to experiment more rapidly, which will impact also the first two advantages: better product and technical innovation.

An important part of a good process is also the ability to continuously refine the process itself, to stay ahead of the competition in the long run.

Processes - especially related to efficient delivery - are something developers have a lot of influence over.

• Become a fast, efficient coder. Learn your IDE in-depth. Get good at debugging. Use tools that speed you up: auto-formatters, code generators, code intelligence, hot reloading, etc. Understand how to organize the codebase to navigate around faster.

• Learn how application architecture impacts not only scalability and performance but also efficient teamwork, code navigation, and debugging.

• Build a robust toolbox of techniques to minimize the number of bugs (and to fix them more efficiently): unit testing, error handling, application monitoring and logging.

• Understand technical debt and how to strike the right balance between cutting too many corners and over-engineering. Become good at making the right compromises between delivering business value and maintaining necessary non-functional features (reliability, performance, security, scalability, maintainability, quality).

• Understand modern delivery processes: CI/CD, Git branching strategies, feature flag-based development, and so on.

• Learn at least the basics of the most popular software development processes (Scrum, Kanban).

• Get accustomed to process improvement techniques (retrospectives, project post-mortems, root-cause analysis, etc.).

• Be open to experimenting, to trying new processes and techniques. Be proactive in proposing and championing improvement ideas. But also know how to balance implementing improvements with generating business value.

Competitive advantage: Operations

The last type of competitive advantage is more efficient operations. Depending on your company's profile you may have different teams involved in acquiring, onboarding, and supporting users: sales, call center, customer success, customer support, implementation, operations, invoicing, and so on. Making these teams faster, cheaper, and more user-friendly is another way to win over over the competition.

How can you help with this as a developer?

• Learn how your various "operations" teams work: what they do day-to-day, what metrics they use to measure their success, what makes them efficient and what slows them down, how they interact with customers.

• Get a good overview of the tools to rapidly build internal tools faster: automatic admin panel generators, CMS frameworks, UI component libraries, and so on.

• Understand the trade-offs of buying vs building vs integrating internal tools (admin panels, invoicing systems, CRM platforms, inventory management and order tracking systems, etc.).

• Know how to most efficiently keep your customer-facing teams updated about the status and expected completion time of your work (for example, bug fixes) so they can easily obtain and pass this information to customers.

• Understand personal data privacy and security issues: how to make your "operations" teams more efficient by providing them tools like user-impersonation or giving them access to user data for tech support purposes without compromising user privacy.

Growth

To become successful, companies need to constantly grow their revenue. It almost always means also growing the team. This, in turn, means more recruitment effort (including onboarding and mentoring), a bigger codebase, more complicated architecture, and increased complexity of organizational structure. It also makes communication, teamwork, and management more challenging - usually to the point where top-down micro-management doesn't cut it anymore.

This sounds like a management problem. But even as a "regular" developer, you can help much more than you think.

• Learn how to modularize the codebase and architecture so multiple teams can collaborate without collisions. Familiarize yourself with Domain Driven Design, micro-services, micro-frontends, API design principles, git repository topologies, and similar. Understand how to evolve the architecture over time, to accommodate the growing size of the platform and the growing number of teams, without over-engineering it early on.

• Learn how to make code easy to read, understand, debug, navigate, and modify for other people. Understand the concept of cognitive load. Get a good grasp of clean code principles.

• Understand what makes the whole engineering organization go faster (design systems, component libraries, coding conventions, UI guidelines, and so on). Understand compromises between what to standardize and what can be different per team.

• Learn how to communicate well (clearly, understandably, concisely, and on-point), both verbally and in writing. Learn how to effectively brainstorm, make decisions together, and navigate disagreement or conflict. Understand how to effectively sync and collaborate with the other teams.

• Find opportunities to help with recruitment. If not by directly participating in the interviews, then by reviewing CVs, preparing and evaluating coding and system design challenges, and promoting your company (through blogging, social media, conferences, or by directly recommending your colleagues).

• Make onboarding easier. Understand and use industry-wide standards to lower the entry point for new hires. Know how to document and explain architecture and logic. Be responsive, non-condescending, and open to answering all questions.

• Help with mentoring. Understand what tasks to assign to someone new or more junior and how frequently to sync with them to not overwhelm them but also not leave them hanging. Be supportive and patient.

• Take ownership of various projects, initiatives, and modules to reduce the burden on management - so they don't have to micro-manage everything.

Sustainability

Companies are long-living entities. Gaining a competitive advantage and achieving initial success is only the start of the game. A company needs to sustain its success over decades.

But when a company is under constant pressure, fighting off new challengers and chasing ever-changing market conditions, it's often necessary to cut corners. Which may put the company at risk further down the road.

To thrive over a long time, a company needs to strike a fine balance between aggressive and sustainable. How can you help maintain this balance?

• Get a good understanding of the concept of technical debt and the ways of managing it. Develop a keen eye for both under and over-engineering. Learn the patterns and principles of code maintainability and evolving complex legacy codebases over time.

• Be aware of the short- and long-term trade-offs between the development speed and the concerns like reliability, performance, scalability, security, privacy, usability, or maintainability.

• Understand short- and long-term implications of various architectural decisions (monolith vs microservices, native vs hybrid mobile, REST vs GraphQL, single-page app vs server-side rendering, monorepo vs multiple repos, and so on).

• Know how to evaluate new technologies not only by the "cool" factor but also by the learning curve, maintenance cost, ease of recruitment, vendor lock-in, long-term support, and similar. Be aware of the build vs buy vs use open source trade-offs.

• Understand how technology choices impact business and UX capabilities and how they broaden or narrow down what the company will be able to solve for its users.

• Don't just passively follow business requests. Participate in setting technical vision and direction and provide guidance and counsel to the rest of the organization.

• Learn how to maintain a healthy lifestyle and avoid burnout.

Adaptability

To stay successful for a long time, sustainability alone is not enough. Companies also have to continuously adapt (or even reinvent themselves).

A company has to adapt to the macro-scale events (changing market conditions, changing customer tastes, new technologies, economic situation, fashion, and social trends) and to the micro-scale events (finishing and starting projects, people leaving and joining, reorganizing teams or departments, adopting new methodologies and processes).

It may, again, seem like something out of the scope of a software developer. But with the right attitude, you can help much more than you think.

• Understand the core principles of empiricism, experimentation, and Agile.

• Be able to quickly pivot and adapt to new trends, tech, and methodologies. Become an eager learner. Know how to learn fast, how to research, and how to efficiently find information.

• Understand how to architect systems to make it easy to gradually migrate parts of them to new tech in the future. Learn how to effectively carry out such migrations.

• Most people dislike and avoid change. Make yourself open to it and comfortable with it. Train yourself to thrive in such an environment. Become good at adapting to new projects, teams, and roles.

• Learn how to quickly build rapport with new people.

• Be open to new points of view, and for updating yours in face of sound evidence.

Bottom line

A purpose of a developer is to make the product and company successful. That's why we're hired. That's why we exist. And modern software is so complex that this process can't be micromanaged. We must proactively contribute to the company's success. Become the experts on the topic.

If you understand the holistic view - what makes companies successful, how the software fits into this puzzle, and how you can influence it as a developer - you'll be invaluable. (And it also opens the door to a future leadership career.)

Plus, it's much more satisfying to understand the whole picture than to just blindly follow what you're told.

In a nutshell

• We work hard to improve our tech and soft skills. But our character traits, our mindset - we take it for granted. An innate, fixed part of who we are. And thus we let it run on autopilot.

• This way of thinking is harmful. Not only is your mindset critical for a successful software development career (maybe even more than your skills) but it's also under your control.

• True senior devs acknowledge that character traits are malleable, are self-aware of their mindset, and deliberately work on it. This is the superpower that makes them stand out from the crowd and accelerates their career.

• In this post, I'll discuss the 10 most critical traits of a successful developer, why are they important, and share a few tips on how you can shape them.

3 things you need to succeed as a software developer

Professional software development is a complex discipline, which requires a diverse set of abilities to succeed. We can group them into three main categories:

Technical skills

This is the most obvious group. To be a successful developer, you need to be good at your trade: programming languages and frameworks, clean code principles, architecture, testing, debugging, and so on. You also need to be skillful with your tools: version control, command line, IDE.

However, technical skills alone won't get you far in a professional, team-based setup. That's why you need also soft skills.

Soft skills

To be able to work on big, commercial projects you need a solid set of soft skills: teamwork, communication, project management and planning, remote work, self-organization, learning, personal productivity, and similar.

Many of us find these skills less fun than the technical ones, and thus we often neglect them - so they can already separate solid, professional developers from the crowd. But at least we acknowledge them.

There's also a third category, though, which is equally important but flies under the radar of almost all, even the otherwise good, developers.

Mindset

Mindset is kinda similar to soft skills, but the "skills" it's comprised of are more fundamental, core traits: curiosity, patience, empathy, grit, adaptability, and so on.

On some level, we know these traits are important for a successful software development career. But because they seem an innate, fixed part of our personality, we do not attempt to deliberately learn them in the same way we learn project management or personal productivity techniques.

This makes us blind to a huge and important part of our skillset and can badly hurt our progression.

Why being blind to your mindset can jeopardize your career

Software development is a complex, sometimes frustrating, and insanely fast-moving field. Learning, growing, and staying relevant as a developer (and not burning out in the process) requires a specific mix of character traits.

At the same time, it's a 100% team game. Lone-wolf hackers have no place in professional software development, no matter how good they are technically. And functioning well in a team requires another, seemingly opposite, set of traits.

Mindset is something different than skills. Understanding Agile development principles is not the same as being adaptable and open to frequent change. And knowing the debugging techniques is not the same as having the curiosity and persistence to actually enjoy chasing the problem for several hours without getting burned out or discouraged. But while these traits may seem fixed, innate to our personality, they are equally learnable as skills.

Without understanding what traits are critical for a programmer and deliberately honing them over time, you'll never reach your full potential. True senior developers know this, are self-aware of their mindset, and continuously work on improving it. This is the differentiator, the superpower that separates the best developers from the crowd.

Ok, but which traits are the most important? Let's dive a bit deeper into the details.

10 traits of a true senior developer

1. Curiosity

If I had to summarize in one sentence what software development is about, I'd say it's about learning. You need to stay up-to-date with constantly evolving technologies and software development processes. You need to learn the deep details of complex business domains (several ones throughout your career). Analyzing and clarifying requirements is learning. Research is learning. Performance optimization and debugging - in other words, poking deeply into the inner workings of code - is a kind of learning as well.

Software development is also about working with people (and for people). You'll be working on cross-functional teams, with a diverse set of people from different specializations and backgrounds (nowadays, in the age of remote, most probably from multiple countries and cultures). You'll have to understand "business". You'll have to understand and solve user pain points and problems.

Without a healthy dose of curiosity, you'll not only be less effective at all those things but you'll also burn out pretty quickly.

2. Affinity for problem-solving

Software development is a giant puzzle - an infinite stream of problems to solve. The reason you are hired as a developer is to solve your company's and customers' problems. To do this, you need to solve organizational problems (how to function as a team, how to organize your work, what processes to use) and technical problems (logic, architecture, performance, and so on). These problems consist of even smaller, nested problems, down to atomic problems like how to design and name a particular function or unit test.

If you don't enjoy solving such puzzles, if you don't have a knack for breaking down and untangling problems, your software development career will be a struggle.

3. Patience

Becoming a true senior developer requires years of deliberate practice. You'll also experience a lot of setbacks along the way. Developing your career is rewarding but also a slow and sometimes painful process. To achieve excellence and get to the top, you must be ready for lifelong dedication. And this requires a lot of patience.

Patience is also critical for a lot of things adjacent to our job: handling technical support, working with not-very-tech-savvy users, coping with organizational bureaucracy. Plus, it's a great problem-solving aid. And you won't sustain working in such a fast-moving, constantly changing industry as tech without patience.

4. Grit (in just the right amount)

Software development requires a lot of persistence. Hunting bugs. Deciphering poorly documented APIs and libraries. Untangling legacy code. Tracking down performance bottlenecks. Even simply sustaining a deep focus for extended periods of time.

You'll struggle, and fail, and get stuck, and get frustrated a lot - no matter how senior you are. And you'll need a lot of grit to plow through and not get burned out.

But you also need to understand what's the right amount of grit. What's the sweet spot between unproductively banging your head against the wall for hours and days vs constantly disrupting your team by requesting assistance immediately when you hit even the smallest bump in the road.

5. Emotional intelligence

Software development revolves around people and teams. You'll work very closely with your colleagues at an individual level: pair program, debug together, review their code. You'll also work with them in a team setup: brainstorm, plan, and make decisions as a group. And this collaboration is messy: your work will overlap or conflict, you'll have different opinions. You'll negotiate your roadmap with management. Finally, to build a great product, you'll have to put yourself in your users' shoes.

On top of that, all these people come from diverse backgrounds, both technical and non-technical. They are passionate. They have strong opinions. They may sometimes have difficult characters. And your success as a developer depends on how well you can build rapport with them. Without high emotional intelligence, it'll simply be impossible.

6. Ability to keep your ego in check

Software development (and working in a team in general) is a balancing act. On one hand, you're hired for your expertise. You're expected to have strong opinions and to guide less tech-savvy or more junior people. On the other hand, you'll work with equally experienced and opinionated teammates, who will challenge your point of view and with whom you'll have to make group decisions.

Your ego will often get hurt in the process. You must be able to keep it in check - but without getting withdrawn and disengaged.

You must be opinionated but not zealot. Have a strong point of view but hold it weakly, be open to getting convinced otherwise. You must be ready to defend your opinion but also know when to let go, to not be a condescending, brilliant jerk. You need to respect the team, business, and customers. Be able to disagree but commit. And gracefully take constructive (and even purely negative) feedback. Otherwise, you won't be able to effectively work in a team.

7. Adaptability

Everything in software development is moving so fast. Technologies are constantly changing. New methodologies get popular. Companies pivot.

Throughout your career, you'll be also changing projects, teams, companies, and business domains. Even a single project is a constant act of inspecting and adapting (especially in agile approaches). And your team will constantly self-reorganize, too.

Most people are allergic to change. Change is hard. It's uncomfortable. It's stressful. Being adaptable and open to change will instantly set you apart. It will not only let you climb to the top of the seniority ladder but it will also let you stay there for a long time.

8. Reliability

I'm repeating it ad nauseam, but software development is a team game. Your colleagues, manager, and company - they all count on you to do your part. Nobody ever will consider you a true senior developer - no matter your tech expertise - if they can't rely on you to take care of your work and deliver on your promises without having to be micromanaged.

It doesn't mean you can never make any mistakes. Failures happen. And the best companies see them as valuable learning opportunities. But to enable this, you need to be able to pick up a dropped ball, gracefully recover, and be trusted to learn from your failure and not repeat it in the future.

9. Pragmatism

Professional software development is an art of tradeoffs. You constantly need to compromise between development speed and quality. Balance new and promising with proven and stable. Walk a thin line between under- and over-engineering.

To succeed in professional software development you need to be very pragmatic. You need to understand that nothing is black and white, that no principle or pattern holds true in every situation. You must have great intuition for making tradeoffs between different approaches, technologies, and solutions; feel comfortable cutting corners but have a good sense of how much.

10. Positive outlook

Your life as a programmer is not all sunshine and rainbows. You'll meet annoying customers. Face tight deadlines. Your project may get canceled. You may disagree with your team or management but still have to commit and execute. You'll also work with ugly code. (Yes, every codebase has good and bad parts, even at the top companies like Google.)

You'll get tired, frustrated, upset.

If you let negativity take over, if you start criticizing and complaining, you'll not only demotivate yourself but you'll also kill the morale of your team - which won't take your career very far.

You need to be biased toward the positive. Be optimistic and cheerful. Always look for a silver lining. Be the person who rallies their team, kills the bad mood, and restores morale. It'll not only get you noticed and promoted, it'll also make your career more pleasant and sustainable.

BONUS: A few tips on how to deliberately shape your mindset

Skills, obviously, can be trained - both soft and technical ones. You can get better at debugging as well as at communication. But what about such seemingly innate traits like curiosity or a positive outlook? Can you really train yourself to be more optimistic or curious?

Yes, you can! This is a vast topic, worth several books ("Mindset" by Carol S. Dweck is a great starting point). But let me quickly share a couple of tips:

• Acknowledge that your mindset is not fixed, that your traits are malleable.

• Build self-awareness. Observe how you react in different situations. Try to understand what makes you feel in a particular way (curious vs bored, positive vs grumpy, eager vs defensive).

• Retrospect on your behavior from a perspective of a day or two. Was your opinion really pragmatic or was it your ego talking? How could you have acted differently?

• Prepare in advance. Pre-plan up-front how you'll behave next time in a similar situation and identify the right trigger that will remind you about your plan when the time comes.

• Expose yourself to situations that will let you exercise and strengthen desired traits. Actively look for such opportunities.

• Focus on a single trait for some time. It will make it easier to find opportunities to exercise it and to increase your self-awareness of this trait.

• Reframe. Be conscious and deliberate about how you talk to yourself. The idea isn't stupid, it's surprising. That shiver isn't anxiety, it's excitement. The problem isn't frustrating, it's interesting.

• Enlist help. Don't shy from asking your colleague or manager for feedback - or even to become your "accountability partner" who will catch and point out your unwanted behavior.

I also encourage you to learn a bit about cognitive biases and habit forming. This is a well-developed discipline, with a huge body of knowledge, and pretty fun to explore.

Bottom line

If you want to be a true senior developer, you have to be a complete one. You must have the right mix of tech skills, soft skills, and character traits and you can't ignore any part of this trio.

Character traits are the most tricky part. Most developers neglect them because they are either not self-aware of them, don't know which ones are important, or don't believe they are malleable.

But if you can overcome this flawed way of thinking - if you can change your mindset - you can turn it into a superpower that will elevate your career and make you truly stand out.

In a nutshell.

• Software development is a team sport. Your individual performance doesn't matter as much as the performance of your whole team and company.

• By improving how you work, you only ADD to your team's performance. By improving how everyone works, you MULTIPLY your team's performance.

• Multiplying the whole team's performance will put you on a much faster lane for being noticed and promoted than being a crazy efficient individual contributor.

• Boosting other people's performance requires different mindset and approach than boosting your individual performance. In this article, I'll show you 16 proven ways to multiply the performance of your team (or even the whole company).

The common misconception of 10x dev.

If you google the term "10x developer", you'll get a lot of results related to individual performance.

Check out the quotes from a few of the topmost results that I've got:

• "A ten times developer is the developer who is ten times more efficient than the average developer on a team."

• "These are the people you want to solve your problems; they’ll do it in 1/10th of the time, with 1/10th of the number of lines of code."

• "I am accustomed to being on teams where I am doing 60% of the work with 7-8 developers on the team."

Statements like these make me cringe.

This. Is. Not. How. We. Build. Modern. Software.

Software development is a team game. Or even a team of teams game. And the game is scored by business outcomes, not raw outputs. By being effective as a team and organization, not efficient as an individual.

As a VP of engineering, I'm not looking for competitive coders. I don't care how many lines of code do you crank in what time. And a single developer doing 60% of the team's work is not something I'd brag about but a dysfunction I'd consider my priority to fix.

So who I am looking for, then? Let's consider the following math:

The simple math of working in a team.

If you improve only your own output, you ADD to the output of your team.

But if you improve every team member's output, you MULTIPLY the output of your team.

And multiplication beats addition pretty quickly.

Even if you truly are a mythical 10x dev, you'll only increase your team's output by 9 "units", no matter the size of the team. But if you improve the whole team's output by just 2x, you'll increase it by 10 "units" for a team of only 10 people. And by 100 "units" for a team of a 100 people.

And we're talking about extreme situation when you are 10 times more efficient than EVERY other developer in the team. In reality, multiplication will beat addition for teams much smaller than 10 people.

Plus, we're talking only about the raw output: how hard do you push, but not in which direction do you push. And the direction the whole team pushes in is critical.

Your team's and your individual performance are connected.

It doesn't matter if a motorboat has a 100 or 1000 horsepower engine if this engine pushes the boat sideways or backwards, not forward. If you push in the wrong direction, you may not only waste your own output - you may undermine the work of your whole team. You can become a -10x developer.

And this relationship is two-sided.

Even if you push in the right direction, your god-mode 10x productivity can be negated if the rest of your team is pushing in the opposite direction.

You need to help them, so they can help you. Cancel the weaknesses of your team so they don't cancel your performance.

It may sound counter-intuitive, but focusing on making your whole team more effective is often a better way to boost also your individual performance than focusing only on your own output.

That's why I and other managers aren't looking for individual efficiency as much as for the capability to positively impact your team. And the broader impact you make - the more people you help go fast in the right direction - the more value you generate for your company.

But don't just take my word for it.

What gets you promoted at most software companies?

Let's take a look at engineering career ladders at a couple of well-known companies:

CircleCI

CircleCI uses a 6-level ladder (E1-E6): Associate Engineer, Engineer, Senior Engineer, Staff Engineer, Senior Staff Engineer, and Principal Engineer.

Levels E1-E3 focus on the execution of work. E1 within task, E2 within epic/project, E3 within team.

Levels E4-E6 utilize skills to scale and generate leverage. They facilitate, guide, and mentor others. E4 within team and with team's business stakeholders, E5 across several teams, E6 across organization.

SOURCE: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0

Carta

Carta uses a 7-level ladder (L2-L8). In their own words:

It’s easy to articulate the single most important thing for leveling: your impact on the company. We can sum up the entire system by describing the (rough) impact we expect employees to have as they progress: on tasks (L2), on features (L3), on problems (L4), on teams (L5), on the organization (L6), on the company (L7), and on the industry (L8).

SOURCE: https://medium.com/building-carta/engineering-levels-at-carta-d33db2a55a20

Spotify

Spotify does't care that much about external titles like senior, staff, or principal developer. They are very flexible about them and let employees choose what makes the most sense for them. But internally, they use 4-level ladder organized by what they call "scopes of impact". And they describe these 4 levels ("steps") like this:

We have identified four Steps in your career path at Spotify. Each Step is marked not only by increased responsibility, but also by your increased impact within tech: Individual Step, Squad/Chapter Step, Tribe/Guild Step, Technology/Company Step.

SOURCE: https://engineering.atspotify.com/2016/02/spotify-technology-career-steps/

Dropbox

Dropbox uses a 7-level ladder (IC1-IC7): Software Engineer 1-4, Staff Software Engineer, Principal Software Engineer, and Senior Principal Software Engineer.

This is how they describe the "extent of influence" for each level:

• IC1: I work within the scope of my team with specific guidance from my manager.

• IC2: I work primarily within the scope of my team with high level guidance from my manager.

• IC3: I work primarily with my direct team and cross-functional partners while driving cross-team collaboration for my project.

• IC4: I am a strong leader for my team with my impact beginning to extend outside my team.

• IC5: I am increasingly influencing the roadmaps of other Dropbox teams to achieve business impacting goals.

• IC6: I typically influence the technical strategy of a group.

• IC7: I typically influence the department and company-wide strategy to achieve business-impacting goals.

SOURCE: https://dropbox.github.io/dbx-career-framework/

I have chosen these 4 companies as they describe their ladders most succintly and thus can be quoted almost directly. But a similar pattern repeats widely across the whole industry.

So what gets you promoted in all these companies? What do they value the most?

Again, the area of the impact that you make.

The bigger chunk of an organization (and the more people) you positively influence, the more valuable you'll be for the company - and the more recognition you'll get.

Operating at such a level may sound scary. But boosting your whole team's performance by 2 or 3x is often less daunting than it sounds. And easier than dialing-up your own individual performance to 10x.

Ok, so how can you do it?

How to impact the performance of the whole team or company?

It's hard to be completely exhaustive, as there are many ways you can positively impact other people's performance. But let's explore several of them so you can get a good gist and build the mindset that will let you come up with further ideas on your own.

1. Teach, mentor, and share your knowledge

Start small. Discuss stuff with your teammates. Spread your knowledge through code reviews, pair programming, and team meetings. Lead by example, through your work and behavior.

Spread your knowledge not only about coding but about anything that may impact your team's performance: processes, communication, time management.

Extend your impact to more people through brownbags, workshops, and blogging. Take opportunities to collaborate with other teams.

Finally, when you're widely recognized as an expert, take responsibility for managing company-wide learning programs or leading communities of practice.

2. Bring new knowledge into the company

Don't be a one-time sensation. Don't rely only on your previous experience.

Learn continuously. Talk to colleagues outside your company. Read. Go to conferences. Stay up to date with the industry's state-of-the-art. Research what other companies are doing. Experiment with new techniques and libraries.

Be the source of innovative knowledge that will help your team reach the next level.

3. Plan and coordinate projects

No matter what process do you use, software development is, in the end, a stream of big and small projects. How well they are analyzed, broken down, planned, and executed has a tremendous impact on the performance of the teams running them.

Volunteering to prepare and lead projects is a great way to impact multiple people's performance.

Start by taking responsibility for one part of the process: requirements analysis, implementation plan, or task breakdown.

Dial it up by owning the process end-to-end, overseeing the whole project execution.

And for maximum impact, take responsibility for coordinating big, cross-team projects.

4. Take ownership of a part of the codebase or product

In complex software systems there are many "moving parts" that need to be maintained over a long time: modules, libraries, subsystems, products, services, APIs, tools, documentation, pipelines, and so on. It's not easy to maintain them well without a clear ownership. And how well they are maintained, has a huge impact on the performance of everyone using them - which, for some cornerstone modules, may even mean everyone in the whole company.

By taking ownership of a part of your company's codebase, product, or subsystem and keeping it in a great shape, you can make an impact that will be hard to miss.

On a smaller scale, you can maintain something internal to your team, for example a small code module or web service.

On a bigger scale, you can maintain something fundamental to the whole product and company, like a central design system or customer-facing API.

5. Improve tooling

Efficient tools make a tremendous difference in how fast a team can go. And there are so many things in our work that can be optimized, automated, or used in a more skillful way.

Solid CI/CD pipeline. Code formatting and linting. Fast test suite. Automated code and test data generation. More efficient code navigation. Utilizing the full power of your IDE. Better local, test, and staging environments. Well configured project management system. Robust tooling for debugging, monitorig, and logging. Better discoverability of components and shared libraries. Automating and connecting your workflows (Github, Slack, Trello, etc.). The list could go on and on.

By improving the tooling, automating repetitive tasks, or even just spreading the knowledge of how to use existing tools better, you can greatly impact the performance of your team and the whole company.

6. Improve codebase and architecture

Put yourself in the shoes of colleagues who will visit the project after you. Easy to understand code and architecture can make or break the whole team's performance. Make them cleaner, simpler, easier to navigate and debug, and less error prone.

Even relatively small improvements, to one component or module, can considerably boost the performance of your team. And the more global improvements - for example, to product-wide code conventions - can impact even the whole company.

7. Help your team go in the right direction

Rallying people together to push towards single, right direction is one of the most powerful ways to multiply the whole team's performance. And you can influence it much more than you think.

First of all, understand the right direction yourself. Put effort into understanding your company's goals, business, and customers. This will allow you to understand what problems need to be solved, and come up with better solutions to these problems.

Second, help your team go in the right direction. Share and document what you learned. Help your team track relevant metrics, gather feedback, and work in a more iterative, agile way. Become a trusted consultant of your product manager.

Third, help coordinate with the other teams and stakeholders, so the whole company goes in a single direction.

8. Support non-developers

Software isn't built only by software developers. It's a concerted effort of developers, designers, testers, product managers, analysts, data scientists, user researchers, and various business stakeholders (customer support, marketing, sales, finance).

Support them. Work closely together. Put effort into making their lives easier, into helping them go fast, into coordinating your efforts so the whole cross-functional group works smoothly together. This will allow you to impact your organization at even broader scope than the engineering team alone.

9. Improve methodologies and processes

How your team and organization works has a fundamental impact on performance. And it's not reserved only for managers and scrum masters. As a developer, you can, too, influence company processes a lot.

First, educate yourself. Understand the principles of empiricism, iterative development, product discovery, and Agile. Get to know modern technical approaches like CI/CD or feature flag-based development. Learn how modern cross-functional teams function.

Second, observe with a critical eye, proactively look for opportunities for improvement, and take the initiative in shaping up the process. Be active inside and outside of your team. Participate in process-related discussions. Champion implementing new ideas.

You'll be able to multiply the performance of many people and teams.

10. Lead technical initiatives

Many technical improvements require a concerted effort of the whole team over a longer period of time: successively replacing old framework with a newer one; migrating to a new set of coding conventions; gradually refactoring a critical part of the codebase.

If they aren't consistently managed and pushed forward, such initiatives usually quickly fizzle out. And their outcomes are mediocre at best.

Volunteer to lead such initiatives. If you plan and manage them well, if you make it easier for other people to contribute, if you coordinate the efforts around them and see them through to completion, you can make a substantial impact on the future performance of your team and organization.

11. Improve communication and transparency

Clear, transparent communication is essential for effective teamwork. It determines how well people coordinate, how much do they trust each other, how good decisions they make, and how well they understand their objectives. And this applies at all levels: inside a team, between teams, between different roles and departments, between employees and management. The quality of communication can hinder or unlock the whole organization's performance.

And you can do a lot to improve it.

Share your status with the other teams. Maintain your team's and company's documentation, roadmaps, and wikis in good state. Help your team stay informed by proactively pulling information from the other teams. Ask management to clarify your team's goals and update them on your progress. Propose improvements to company-wide communication standards and channels (Slack, etc.). Initiate cross-team coordination meetings whenever necessary.

12. Exemplify and promote culture

There's no single right culture. Different companies conduct themselves differently with a similar level of success. But if different people, teams, and departments in the same company culturally clash, it kills productivity.

Understand your company's culture. Exemplify and promote it. Be conscious of your behaviour and communication patterns.

It impacts your company's performance more than you think.

13. Motivate others

Sometimes, reaching higher performance is just a matter of motivation. The willingness to push harder. Feeling more hungry for success. Having the right attitude.

You don't have to be a manager to influence your team's morale. Lead by example. Spread good vibes. Show enthusiasm, optimism, and grit. Make the work fun. Stay calm and composed in a crisis. Rally your team to push a little bit more every day.

Such behaviours are viral and frequently work better than attempts to "empower" people from the top. And they easily spread outside of your team, which will let you make a broad impact.

14. Help with recruitment and onboarding

Another way to boost organization's performance is through recruitment.

If you can, get involved in the recruitment process. Participate in the interviews. Help prepare recruitment challenges. Review CVs.

And even if you can't participate in the recruitment process itself, there's still a lot you can do to help bring new talent onboard. Refer your colleagues. Promote your company through blogging, discussion forums, speaking on conferences, and networking. Leave a positive review on Glassdoor. Take responsibility for onboarding and mentoring new hires.

15. Solve complex problems (and then spread the knowledge)

If you can solve a problem no one else is able to solve, such that will give your company a competitive advantage, you can generate a ton of value.

This may sound like a task for a lone, 10x genius, but it is still about the team. If you won't spread the knowledge about your brilliant solution, if you won't design it so it's easy for others to reuse, you'll become a bottleneck and a potential single point of failure instead of a multiplier. You'll put your company at risk, not bring value.

But if you can solve complex problems in such a way that everyone understands your solution and is able to build on top of it, you can become a game changer.

16. Provide technical direction and advice

Your company often needs to cope with decisions with a huge, long lasting impact. Choosing a technology stack. Choosing a cloud vendor. Making build vs buy decisions.

Even more often, smaller questions pop-up: What would be the rough size of the project? Is it technically feasible? What are the possible soutions to this problem?

Become a go-to advisor for your team and for the whole business. Learn the industry's landscape in-depth. Stay up-to-date with the newest developments and trends. Get good at research. It'll let you bring a lot of value for your company.

"But can I really do all of this as a developer?"

Can you really own subsystems, lead projects, or make build vs buy decisions? Isn't it the responsibility of architects, managers, and tech leads?

Yes, you can! In any well-run company, your manager or tech lead will be glad to delegate as much as possible to you. This is actually their job. It helps you grow and your team perform better, which are the most important responsibilities of a manager.

Some of the higher-impact stuff may indeed require more experience - nobody will let a juinor straight out of a coding bootcamp to own a mission-critical subsystem used by all the teams in company. But all the impacts we discussed have a gradual progression.

Start with smaller initiatives, in your team, and successively expand the scope of your impact. Work with your lead or manager to find more opportunities for growth. Be on the constant lookout for such opportunities yourself, in your team and across the company. Get noticed and build reputation.

This will set you on a fast track to make bigger and bigger splash. To become not only 10x but even a 100x developer. And - if this is your ambition - to eventually become a tech lead yourself.

Bottom line

Yes, you need to be a solid developer. It's hard to be multiplier for others while doing a crappy work yourself. But don't sweat it if you are really 10x, or 5x, or just a solid 1x. Shift your mindset from personal efficiency to effectiveness of the whole team and company. And when you do, only the sky (and your company's size) is the limit. You can become not only 10x dev, but even 100x and more.

In a nutshell

• We instinctively equate programming with writing code. Because of it, we focus primarily on code design and creation skills: mastering languages and frameworks, clean code, design patterns, TDD, architecture.

• But creating new code is only a fraction of what we do every day. We spend much more time navigating, searching, analyzing, reviewing, and debugging code than writing.

• Though these activities seem straightforward, they require as specialized skills and experience as coding. Mastering them is what separates true senior programmers from the crowd. And what makes you stand out and get noticed at a new job.

• In this post, I'll look at the key traits of professional software development, how they impact what you do every day, and explore what skills do you need to become a complete programmer.

The common misconception about programming

People instinctively equate programming with writing code. And it doesn't apply only to lay people. Many experienced programmers also do have this bias. Not in a naive way, of course. We know that coding isn't just typing and that having crazy keyboard skills doesn't make you a great programmer. But even then, we focus mainly on code creation skills.

Think for a moment what most books, blog posts, and talks are about. What sparks the most heated discussions in your team. What are the most common coding interview questions.

Clean code. Deep, almost arcane knowledge of programming languages and frameworks. Design patterns. Architecture. Algorithms and data structures. Writing beautiful unit tests.

Those are fundamental skills, yes. But they still focus mostly on code creation.

I'm not saying these skills aren't important. They are critical for a senior developer. And there's so much depth there that they can be studied for years. But they cover only a small fraction of what we do every day. And focusing only on code creation skills, while neglecting the rest, will make you a very incomplete and ineffective programmer.

To call yourself a true senior programmer, you need a well-rounded skill set. But in order to develop this skill set, you first need to acknowledge what actually defines how we work.

What professional software development really looks like

Professional software development has a few traits, which have a profound impact on what we do every day as programmers:

1. Software development is a team activity and most of the software is long-living. What this means in practice is that the majority of the code you'll work with was either written by someone else, modified by someone else since you wrote it, or written by you sufficiently long ago to forget it. It also means that most of the code you'll work with will be legacy.

2. Humans are prone to mistakes. No matter how experienced you are, how rigorous is your process, and how clean and modular is your codebase, you'll still introduce errors. And a lot of them. They may not (hopefully) land on production if your Quality Assurance process is tight, but during local development, you'll have to constantly cope with bugs.

3. Modern software stacks are too complex to learn everything by heart. The number of technologies, the surface area of all the APIs, and the pace of updates are simply too high. Even if you are a seasoned programmer, working for years with one stack, it's impossible to just continuously write code without pausing to look stuff up.

4. Commercial software is built under tight time and resource constraints. Unless it's your personal hobby project, you'll be constantly struggling to balance cutting corners (to generate business value faster) and keeping the codebase healthy (to not cannibalize your long-term performance).

5. Understanding a new codebase quickly is a critical career skill. In a new job, the first impression you make sets up how you'll be seen for a long time (if not forever). And it depends on how fast and self-sufficiently you can find your way around the new codebase. If you are able to start meaningfully contributing right off the bat without much guidance, you'll be immediately perceived as a strong senior.

When you look at the above 5 traits, you can clearly see that your most important skills are the ones related to reading, analyzing, and reviewing code, navigating unknown code bases, debugging, finding information, and being able to walk a thin line between under- and over-engineering.

But let's explore these skills more in-depth.

What a well-rounded developer MUST be skilled at

Exploring and understanding new codebases (a.k.a. code archaeology)

Mapping the lay of the land. "Reading" the overall layout of the codebase (directory structure, architectural layers, main business domains) and building a mental model of the flow of data and logic through the application. Knowing how to efficiently map, diagram, and visualize the code, data, and flow.

Navigating and searching the code. Using the full power of your IDE to efficiently find your way around the codebase: navigate up and down component or inheritance hierarchy; navigate up and down function or method call chain; look up the definition of the function, class, component, or constant; look up the dependencies of a class, function, or component; find all the occurrences of a class, function, or variable; quickly switch between code and related tests; quickly find component, class, function, or constant by name. BONUS: knowing how to structure the codebase and name stuff to make it easily navigable.

Exploring the Git history. Effectively navigating through the commit and pull request history to understand the context and the decisions behind the current state of the code. Using tools like git blame to identify where to find the necessary information. BONUS: writing good commit and pull request descriptions that will make exploring Git history easier for other developers.

Exploratory testing and code inspection. Using manual and automated end-to-end exploratory tests to see how the application works (which is often hard to understand from the source code alone). Stubbing API requests with fake data to get the application into the desired state to explore all the edge cases. Peeking into the application's inner workings by the means of characterization unit tests, debuggers, and inspection tools (web browser dev tools, interactive shells, request capturing tools like Postman, etc.).

Debugging

Understanding the overall debugging principles and approaches. Top-down vs bottom-up debugging. Divide and conquer approach. Tradeoffs of using different approaches to pinpoint the problem (for example, debugger vs "print" statement). What input data to use to most efficiently replicate the bug, and at what level to insert this data: UI, web requests, or somewhere inside the code.

Debugging and inspecting the code. Deep knowledge of the whole range of debugging tools and approaches: integrated and external debuggers, "print" statement and equivalents like browser's console.log, in-code assertions, using unit tests to debug the code, using git bisect. Deep knowledge of the tools to inspect and interact with the running application: browser dev tools, your framework dev tools (for example, React or Redux dev tools), interactive shells, tools like Postman to capture and inspect API requests, and so on.

Interpreting and following error messages. Knowing the most common error messages of your language and framework. Understanding how they are formatted and what additional info they contain. Tracing error messages to the actual place in the source code (knowing how to interpret stack traces, use tools like source maps, and so on). Looking up less common error messages.

Monitoring and logging. Using server and cloud platforms' logs to detect and triage errors. Using log management and visualization tools like Grafana, Kibana, or Splunk to pinpoint errors easier. Utilizing monitoring tools like Sentry, AppSignal, or NewRelic.

Reviewing code

Understanding the context. Discerning what the original code does and what the change was intended to do. Building a mental map of what exactly was changed and how it impacts the workings of the app. Using tools like your IDE, Git command line, and Git UIs to effectively navigate code and diffs to understand the changes and their context.

Understanding what to focus on. Which changes are critical and which ones are cosmetic. Which will impact code security, architecture, readability, and long-term maintainability, and which ones are more a matter of personal taste (and should be left to the pull request author). What requires human analysis and what can be left for linters and code formatters.

Efficiently reviewing (and re-reviewing) the code. Efficiently navigating through the changes and the discussion (other reviewers' suggestions, pull request author's replies). Understanding how to most effectively review a PR depending on its size, complexity, and quality of individual commits (if it should be reviewed commit-by-commit or all the changes altogether, etc.). Utilizing more advanced features of your code hosting platform like GitHub's multi-line comments or suggested changes. Effectively re-reviewing fixes applied by the code author to your (and other reviewers') suggestions.

Collaborating with the author and other reviewers. Writing constructive, non-aggressive, easy-to-understand suggestions, that are helpful to the pull request author and the rest of the team. Clearly distinguishing the "must-fix" suggestions from the "for-the-purpose-of-the-discussion" ones. Knowing when to press and when to step back - and when and how to gracefully end the discussion.

BONUS: Making your pull requests easy to review. Writing great pull request and commit descriptions. Knowing how to make a pull request easier to review: when to do one bigger commit vs multiple smaller ones, what should be the pull request boundaries, and so on.

Finding information

Having a good understanding of the documentation for your stack of choice (how is it organized and how to most efficiently find what you need). Getting good at looking up stuff on the internet (Google, StackOverflow, etc.). Using the full power of your IDE: inline documentation, parameter hints, go to definition, and so on.

Working with legacy code

Understanding technical debt. Understanding the tradeoffs between under- and over-engineering: which debt is worth paying off right now, later, and never; which should be paid off gradually and which as a one-off, bigger project. Setting boundaries of what should be paid off in the current batch. Understanding how to work during the transition period when paying tech debt gradually.

Isolating legacy code and covering it with a safety net. Identifying natural boundaries ("seams") to isolate areas of legacy code for controlled, limited changes. Covering the isolated area with the temporary characterization tests at the seams, to provide a safety net against the regression during refactoring. Converting characterization tests to the proper focused unit tests after refactoring.

Restructuring and refactoring the old code. Knowledge of refactoring patterns and techniques (especially extracting and modularizing the code to contain the scope of the refactoring). Using your IDE, codemods, linter auto-fix, and similar automated refactoring tools.

Bottom line

If you want to advance your career, you have to be a complete package. Code archaeology, debugging, reviewing code, finding information, and working with legacy code, are absolutely critical skills to have (especially as a complete bundle, as they interact and reinforce each other).

Not only you'll spend more time on these activities than on the actual code creation - but they also enhance your creation skills. And they are what screams "true senior" to your colleagues and managers.