Ask HN: I've lost faith in myself as a developer, how do I get it back?
&gt; or get called out on not doing things the &quot;right&quot; way.<p>I think this specifically might be part of what&#x27;s causing a challenge for you...<p>If you were a software developer for 4 years and then a CTO for 8, I&#x27;m guessing that you&#x27;re quite a generalist.  And a pretty talented one.  You&#x27;re likely able to think (and communicate) very effectively about higher level strategy&#x2F;architecture as well as work down in the detail.  This is a valuable and rare skill, and it&#x27;s this ability to work at different levels of abstraction which makes you valuable to the company and not necessarily just your &quot;raw&quot; software development skills at this point.<p>Being a CTO you&#x27;re probably also a little rusty (unless you&#x27;re a very active hybrid coder&#x2F;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.<p>At the same time, you probably work with people, perhaps on your team, who are talented <i>specialists</i>.  Not generalists.  Ie. on the surface, perhaps you think they are better developers than you?  (Or perhaps you think that <i>they</i> think that?). Perhaps you see them using newer technologies or design patterns that you&#x27;re not as familiar with and that leads you to doubt yourself.<p>I&#x27;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&#x27;ve ever worked with, even to this day.  And there were certainly times when I&#x27;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&#x27;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.<p>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 <i>obstensibly</i> smarter than you is about the best thing you can do in any career.  And if they&#x27;re <i>not</i> smarter than you, then cool.  They&#x27;re not smarter than you.  Either way it&#x27;s a win! :-)<p>However.  The MOST important thing I would say, is don&#x27;t judge yourself as a developer, judge yourself as a CTO.  That&#x27;s the role you&#x27;re in.  Some CTOs can&#x27;t code at all.  So you&#x27;re already ahead of the pack.  And try to remind yourself that even if you don&#x27;t use the latest fancy design patterns or technologies - this actually has very little bearing on how productive&#x2F;useful you are in your position.  Sometimes those things are complete distractions and actually in reality add zero <i>actual value</i> to the business.  (Sometimes).<p>With our developer hats on, we can sometimes get a little narrow-minded and work to produce the &quot;perfect&quot; 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 &#x2F; shareholders literally don&#x27;t know the difference.  As long as that PHP solution is fit for purpose, nor should they.  It&#x27;s irrelevant.  There can sometimes be a divide between what an engineering team &quot;thinks&quot; is best vs what is <i>actually</i> 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.<p>So if your MO is throwing together some crappy looking code that works.  Own it.  You&#x27;re the damn CTO and that&#x27;s fine.  Learn from others by all means, but don&#x27;t doubt your approach either, it may be way more valid than you think.  You also don&#x27;t need to be the strongest coder.  You can be the best CTO in the world and be the worst coder in the company.<p>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&#x27;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&#x2F;pattern.<p>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 &quot;default&quot; state was to often feel like a bit of an imposter and have similar worries to you.<p>TLDR; You probably deserve to give yourself more credit than you are.<p>Good luck!