Clint McMahon Clint McMahon

Be A T-Shaped Developer

I answered a question on the /r/learnprogramming subreddit about whether engineers should have expertise or deeper knowledge in more than a single area of tech. Yes, absolutely. More and more jobs require developers to know more than a single domain. Knowing front end, back end, ML, databases, CSS, etc. will help you in your career. On top of knowing different technologies, it's important to be an expert in one domain while being comfortable in others as well. Someone commented below my comment that "this is called being a T-Shaped Engineer". I've never heard that before so I looked it up.

A T-Shaped engineer is someone who has deep expertise in one area (the vertical part of the T) and knows enough across the board (front end, back end, database, web servers, etc.) to get things done with the rest of the team (the horizontal part of the T). That depth is what lets them solve hard problems in their niche or area of expertise. For me, that's C#. The horizontal is what makes them valuable in a room full of specialists. They can talk architecture with backend folks, UX with designers, troubleshoot CI/CD with DevOps and still build great features in their specific domain or language. It's the difference between being just good at coding and being the kind of engineer that can deliver an entire application. This is especially important, if not mandatory, for consultants and freelancers.

Since my first job and in every job since, in my 20 years of being a software engineer, it's always been important to understand more than a single domain. I can't think of any job that only required me to write C# code and not know anything else—like IIS management, writing SQL queries, or managing CI/CD deployments. The technologies are always changing, but the idea is the same: always be learning and growing.

My Evolution: C# + Everything Else

Starting as a VB6 developer and growing into a C# engineer as my core expertise, I've added horizontal skills that clients actually need:

  • True full-stack development. When a client hires me to create software, they get a complete software agency in a single person. I discuss requirements with stakeholders, write utility programs that aggregate data sources into a single SQL Server database, create scalable APIs to deliver the data to the internet, and develop interactive UI/UX web pages that accurately display data to end users.
  • Soft skills for stakeholder communication. Over the years, I've worked hard to develop my soft skills to discuss anything from project design requirements to budgets with different stakeholders throughout an organization. I'm naturally a pretty friendly person, so having conversations with tech staff, doctors, and business executives comes pretty naturally to me.
  • Server management and troubleshooting. Time and time again, I've had to debug why a website wasn't behaving as intended—either it was slow, unresponsive, or throwing a 500 error. Being the consultant who's comfortable with server management and maintenance is key for my clients and my work as a consultant.

These skills that fall outside of my C# software engineering expertise are incredibly valuable to my clients.

One Example That Shows Why This Matters

One of the best examples I point to is an application that I created that incorporates product development, requirements gathering from stakeholders of all technical abilities, data analytics, database design, database development, API development, and front-end data visualizations. This is a concrete example of where my T-shaped engineer skills not only solved this client's problem but also saved them money because they didn't need to hire an entire software development agency to implement this solution.

How to Build Your Own T-Shape

Recognize your vertical: Find out what your vertical in the T is and develop that skill deeply. If it doesn't jump out at you, don't sweat it. Figure out what you're most passionate about and follow that skill. Learn everything you can and stay on top of that skill. If you love building databases, make SQL or database design your deep vertical, or lean into C#.

Add horizontal skills: Outside of React and various front-end frameworks, my horizontal axis skills have all come from demand on the job. Clients want to have someone who can build, deploy, and manage their software systems. For example, because of client demands, I've built up my skills to include Windows and Azure server management. My career isn't short of managers or clients asking me to do something that I have no idea how to do. In that situation, I just tell them to give me a little bit of time to work on the problem and jump in. There's always a little bit of fear that I don't know what I'm doing, but I always come away having solved the problem, and because of that, my tool belt gets a little bigger.

Learn through projects and demand: My approach to practical learning is to say yes to everything that you are challenged with. This shouldn't be confused with saying yes to every demand a client or manager throws at you—that's different, as there is great power in the ability to say no.

This approach is about jumping right in and trying to solve it whenever I'm faced with a problem. Doesn't matter if it's not in my expertise; I will try to figure it out anyway. Along the way, I'll ask other people who are experts in this domain for help. This helps me understand problems and solutions better. With LLMs and AI, this is so much easier than it's ever been. Don't be afraid of being wrong or not figuring it out—just have faith that you can and will figure out the problem.

The Bottom Line

In 20 years, I've never had a job that only required me to code C# in a dark corner. Developers who thrive are those who can contribute across the stack while solving hard problems in their specialty.

Don't be afraid to get your hands dirty or say "I don't know, but I'll figure it out." Being able to admit you don't know something means a lot to managers and clients, especially if you're the one who is still going to solve the problem.