Ask HN: I've lost faith in myself as a developer, how do I get it back?

> or get called out on not doing things the "right" way.

I think this specifically might be part of what's causing a challenge for you...

If you were a software developer for 4 years and then a CTO for 8, I'm guessing that you're quite a generalist. And a pretty talented one. You're likely able to think (and communicate) very effectively about higher level strategy/architecture as well as work down in the detail. This is a valuable and rare skill, and it's this ability to work at different levels of abstraction which makes you valuable to the company and not necessarily just your "raw" software development skills at this point.

Being a CTO you're probably also a little rusty (unless you're a very active hybrid coder/CTO). The best developer in the world would get a bit rusty after doing what is often NOT really a software development job for a while. So if this is the case, you can cut yourself some slack there.

At the same time, you probably work with people, perhaps on your team, who are talented specialists. Not generalists. Ie. on the surface, perhaps you think they are better developers than you? (Or perhaps you think that they think that?). Perhaps you see them using newer technologies or design patterns that you're not as familiar with and that leads you to doubt yourself.

I've definitely been there. (So I may be projecting a little here). As an engineering manager (sort of a pseudo-CTO in our small business) my first hire was an incredibly smart guy. The smartest developer I've ever worked with, even to this day. And there were certainly times when I'd doubt myself in his presence. I felt like he was often several steps ahead of me. Fortunately he was also the nicest guy I've ever worked with, so while he would certainly tell me if he thought I was doing something wrong, I would encourage him to do so, and always knew that it was coming from a place of good intentions. Even if I had to occasionally swallow my pride! I saw it as an opportunity to grow and as an exercise in humility too! He was often right too, but not always.

Anyway, I became a _much_ stronger developer and technologist as a result of having the good fortune to work with him for several years. And you will too if you have the good fortune to be working with a very smart team. Even if you doubt yourself at times. Working with people who are obstensibly smarter than you is about the best thing you can do in any career. And if they're not smarter than you, then cool. They're not smarter than you. Either way it's a win! :-)

However. The MOST important thing I would say, is don't judge yourself as a developer, judge yourself as a CTO. That's the role you're in. Some CTOs can't code at all. So you're already ahead of the pack. And try to remind yourself that even if you don't use the latest fancy design patterns or technologies - this actually has very little bearing on how productive/useful you are in your position. Sometimes those things are complete distractions and actually in reality add zero actual value to the business. (Sometimes).

With our developer hats on, we can sometimes get a little narrow-minded and work to produce the "perfect" piece of code that conforms to all the SOLID principles, fully tested, extensible, using the latest shiny language etc. etc. when a competitor of the business may have just thrown something together in PHP (sorry PHP people) and are still delivering the exact same outward-facing value to their customers. And their management team / shareholders literally don't know the difference. As long as that PHP solution is fit for purpose, nor should they. It's irrelevant. There can sometimes be a divide between what an engineering team "thinks" is best vs what is actually best given all the context that you as a CTO may know about the business and its priorities vs the view of the world that they may have.

So if your MO is throwing together some crappy looking code that works. Own it. You're the damn CTO and that's fine. Learn from others by all means, but don't doubt your approach either, it may be way more valid than you think. You also don't need to be the strongest coder. You can be the best CTO in the world and be the worst coder in the company.

Finally, my last piece of advice is to jump on something like www.pluralsight.com and speed-watch courses in areas that you think you might be weak on. I did this during my years as pseudo-CTO to quickly get up to speed with technologies that I wasn't necessarily working with every day, either to be able to talk intelligently about it with my team, or (at the best times) be a able to dip into coding and actually bring the team up to speed with that new technology/pattern.

By absorbing online courses like that, and blogs, and HN, as well as having quite a lot of engaging side projects, I was able to stay pretty sharp and still teach my team a thing of two - even the smartest of them - even when my "default" state was to often feel like a bit of an imposter and have similar worries to you.

TLDR; You probably deserve to give yourself more credit than you are.

Good luck!

easy. Build something.

Thanks for the thoughtful reply. Lots to digest, but that's a good thing.

The thing that jumped out the most to me that you said is dedicating myself service. I have been thinking that I should spend time helping others rather than focusing on myself so much. Not only does it help them it helps you appreciate what you have I would imagine.

I've also been considering a sabbatical to get myself back into a good mental state. I'm lucky enough where that could be an option so maybe I need to consider that more as I transition out of the CTO role.

Thanks again!

Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions. Type 1 decisions are one-way door decisions that needs to be deliberated deeply and consulted on with higher-ups. Type 2 decisions are two-way door decisions that small teams can be empowered to make.

There is a balance between empowerment and the higher-ups taking responsibility. I've been in an organization where-in the higher-ups just abdicated all responsibility and avoided making any technical decision (maybe for fear of making a wrong decision) and so the small teams had to make every decision which led to chaos and lack of direction.

Sometimes, it is the job of the architect or CTO to make those big decisions; their job is not to code, their job is to weigh the possible options and make a decision to give direction to the team.

I had this exact same experience at a previous startup. It was really frustrating to me, it was so easy for new devs joining the team to criticize past work. It was especially difficult for me because I'm not a natural leader and I tend to avoid conflict. On top of that, I already knew I was cutting corners, it's just impossible when I was the only developer and was forced to make tradeoffs and meet deadlines all the time. But the new team members weren't around for those times so they were blind to previous state.

I'm now working for a different startup of very smart people and engineers and see that it's just normal to have all kinds of tech debt. My previous experience has given me valuable perspective, I don't complain about how/why things are the way they are I just do the best I can to improve it and ship features.