Ask HN: I've lost faith in myself as a developer, how do I get it back?
I've been a software developer for about 12 years, the last 8 of which I have been the CTO of a company that is growing like crazy. Recently I have been doubting every move that I make and have lost all faith in myself as a developer. When I look at a new feature I just think that I will make it shitty or get called out on not doing things the "right" way. The thing is, I know I'm a decent developer but I find myself doubting every single decision that I make. Is this burn out? How can I get out of this funk and move on?
239 comments
[ 3.3 ms ] story [ 147 ms ] threadJokes aside, did something happen before? Did a software not perform or caused problems? You say growth is fast. Sounds good and that means to make compromises here and there in software that might not fit your aspirations of quality.
Is this a new position? Or did you see a topic that was just beyond you in any conceivable way? I guess making wrong decisions comes with the job, but as long as business is good...
I think I am questioning my abilities because we built things in questionable ways and now everything that I have done is being scrutinized by all new team members. It's really hard to deal with that constant barrage of "why did you do it this way" all the time.
Classic. I know brilliant people who wrote pretty ugly code years ago and beat themselves up about now (in a tongue-in-cheek way -- they joke about it frequently).
Coding is hard; if it was easy, people as smart as them would've written stuff perfectly the first time!
Moreover, in the early days of a new company, the priority is to get something working to create income - sometimes, quality be damned. Otherwise, there's a good chance the company won't survive to get the chance to hire people who will get the opportunity to criticize the code that made their employment possible.
In the end you may move more towards explaining to people how the company operates, how the data is processed and keep that going.
My only advice is you should be open-minded to the newer devs who work day-to-day with the “legacy” systems you originally wrote and may have very informed ideas about how to improve or refactor those systems. It’s not a knock on you, the company is simply in a different stage.
Reading old code with a critical eye is an important part of working on a mature code base.
If an arrogant developer reads some questionable code, they will think "the author must have been stupid." They will ask this question as a way to satisfy their narcissism.
If a thoughtful developer finds some questionable code, they will think "the author must have had some motivation that I don't know about." They will ask this question to help them understand the system design and do better work.
Both attitudes lead to the same question. You could start by assuming your new team members are thoughtful and want to learn. They will understand that "we were under time pressure" or "we didn't know about xxxx technique" is a valid answer to "why did you do it this way."
If you discover that your new team members have narcissistic tendencies, then you have a much bigger problem than justifying your own past decisions.
We have the time now for refactoring ... or we'll add a ticket to the backlog, etc.
Second, everyone looks at some code, wonders what idiot did this ... and at some point discovers it was themselves x months/years ago. If you're the primary coder, you'll be getting this a lot. Accept that you've learned and improved since then.
Hope this helps.
I all too frequently wonder who wrote this and see that it was me. You're right that it's a good sign of growth :).
I demanded help when the product was on the market and the new dev began to refactor parts of the software. Was awesome to have help and the new dev teased me when he discovered my greatest sins and most idiotic decisions that I committed. Wasn't meant seriously from his side, but at some point it nagged on me nonetheless because he was a bit of a smartass at times.
Helped me to reflect what I implemented with the resources and time that I had. You will rarely be happy with the code and design decisions you made yesterday anyway. Learn from the mistake and move on. A dev that never wrote bad code probably didn't write much to begin with. People that constantly question design decisions often might just want to prove themselves to you or honestly want to know why you did it. I often answer something like "I was full of optimism about it at that time".
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.
Your best bet is to do a project entirely different from anything you've done in a while. You can vary: (1) the domain of the project (what it's about) and (2) the technology behind the project.
When I was really sick and tired of programming I enjoyed playing with Scratch with kids. Many coders, including myself, have a blast with Arduino and other embedded boards.
Years ago I took the Myers-Britt test and was an INTP. In the last year I picked up an art hobby (with a lot of coding skills) and have been doing a lot of reading and other work relative to art and relationships and I retested as an INFP. Now my heroes are people like Walt Disney and Jim Henson. I wouldn’t be surprised if I test as an ENFP a year from now.
For me the trick is to just begin, no matter how small the initial step is.
I think what really triggers curiosity is the ability to learn new things while making an okay progress.
I knew some CTO's that wrote the initial code (ergo, code quality totally sucked), or would write a 1-off extension (where the code quality didn't matter much). Once the company achieved some size (>5 developers) they just didn't do it anymore / it wasn't a quality use of their time.
As they matured, they tended to focus on the data schema and the soa architecture, and less on the bits and bytes of functions and frameworks.
What drives you to keep being the primary coder?
How big is this company?
Is it a small company with few developers where you hold the CTO title because you're a founding developer or the most senior developer? If so, you might be missing the reassurance that came from your previous life where you had a manager to check your work, peers to review it, and feedback from people who didn't report to you:
> When I look at a new feature I just think that I will make it shitty or get called out on not doing things the "right" way.
At a startup, the "right" way isn't necessarily the most textbook-perfect code. The right way is getting features shipped as soon as possible with the code being good enough to be understandable, stable, and maintainable. You need to be careful about spiraling into decision paralysis or drawn out refactor iterations and instead focus more on shipping features to users, focusing effort where it matters for the business, and avoiding unnecessary complication in search of perfection. Perfectionism will kill startups slowly.
If you're the CTO of a big company with many developers reporting to you, then it's time to start letting go of the developer responsibilities. Trying to manage the code too closely or trying to insert yourself into the development teams that you're supposed to be managing doesn't work at scale. Focus on the bigger picture: Driving objectives, mentoring developers, hiring, monitoring output, and other leadership roles. Don't let a desire to control the code interfere with your management duties.
You hit the nail on the head though, I got the role because I was the first engineer and employee at the company. In no way am I a great CTO, just lucky timing.
I'm actually stepping down as CTO and becoming a developer again because I am not a good manager, that I know for sure.
I think I need to be better about getting over perfectionism. I think I let it haunt me that everyone looks up to me with my title as if I should be the best when I am very much not. Thanks for the thoughts here, I really need to reflect on this some more.
> In no way am I a great CTO
> I am not a good manager
It sounds to me like one core thing you learned is that good developer != good manager != good CTO. With that said, all three skills are different, but improved in the same way. Practice and with focused attention. It sounds to me like you were still focused on development and never really gave yourself a chance to develop those management and CTO skills.
It may still be the right call to step down, but I would at least consider trying to shift your focus to the other skills instead of development, if a leadership role is of any interest to you long term. You could also step down to a manager role so you can focus on one of the two at a time. If the learning here is that you actually don't want to focus on those skills over development, then nevermind this for the most part :)
I don't know what you want for your future, but many of us have transitioned from dev roles to management. If you are going to be an engineer long-term, then stepping down from CTO may make sense. However, if in the next 5-10 years you want to become "management" then you are going to have to learn how to manage people. You are going to develop less. Your team should be better at developing than you are.
If you eventually want to manage, you will have to learn the skills. So why not focus on getting better at CTO now? You'll be 5-10 years ahead of where you'd otherwise be. CTO roles don't come around every day.
Just my two cents.
Kudos that you've taken that decision - it's a good one. You can take the time to really broaden your horizons. At which point I very much expect that you'll go back, but as someone who earned the respect, not someone who needs to demand it.
No harm to step down or out for a bit and come back to it when you're ready if you're burned out. Rotating the management and developer duties might reduce your pressure if it makes you feel you've got more back up.
Consider pair programming if you're doubting yourself, maybe with both weaker and stronger developers to help benchmark your skills more accurately.
External training or mentorship might help you to get another perspective on your skillset.
Also consider whether there are any external factors such as your upstream management, clients, or the market that you are in that are stressing you out. It may be that the worries about development skills are symptoms of another issue.
As a senior team member, you should have a lot of scope to choose the work that you think is the best fit for you. Taking some time to think about this is part of being a manager, and as a senior developer your development skills are not something you need to worry about too much - you can bring these up quickly if you need to, and you probably don't need to right now. You've gone through a stage of worrying about what you can bring technically to the table, and that's not your focus right now, which feels uncomfortable. It's OK to follow the flow of your career and see what happens, you can reset down the line if needed.
My suggestion is, DON'T.
Please see my other comment in this thread for some suggestions. Opportunities like this do not come often and it is a mistake to give up what you have achieved without a great deal of deliberate thought.
As others have noted I agree that building something (even not software related) helps get me out of these kinds of funks. The reality of your position is that you likely are at a point where you have hired people to make the important technical decisions in terms or architecture, design, and "engineering" and you hired them because they are specialists at that. In todays dev world there is too much to know about to many things to keep full grasp on it all. Your job as a technical leader is to drive the trajectory of the project in the right direction and that often means trusting the leaders of various teams to make decisions about individual technical topics so long as it meets your higher level goals as an organization. Remember Wernher von Braun was not designing every piece of the Saturn V he was driving the project to success.
Meet-ups, hackathons etc are good ways to stay up to date on diverse topics & letting your brain work on new stuff instead.
I left. My new job has lots of tech debt, lots of processes that are broken, but when I propose changes people listen. When I put in the work I can see progress. It's hard work and frustrating, but I know that it's because the problems I'm tackling are hard, not because I'm a failure or lacking. That's a very different environment.
I can only give a very broad bit of advice here -- having a positive, open environment is very important. Gaslighting will bring down even the most secure, confident person over time. If you can't change the environment, leaving to find a better one is the right thing to do. What that looks like will differ on one's situation -- might be a long break from coding, might be changing teams, might be changing companies. But we absolutely need people around us who believe in us to work sustainably.
The company itself is great. All of the feedback I receive is very respectful and understanding, it still just eats at me though. We're even working on a plan to address some of the tech debt/complexity in 2022.
I think my self-doubt is just being on a podium at work teamed up with being burnt out. Maybe an extended vacation is really what I need to do.
100% adding a +1 here that this sounds like the right thing to do to start.
> it still just eats at me though
To me, this stands out. I think it's important to answer the "why" here at some point, whether that be before/during/after an extended break. Some potential things to investigate:
- Maybe the company is respectful, but the environment is still too critical / focused on bettering code constantly rather than focusing on product.
- Maybe there's too much focus on code quality over product generally, to the point that it's not helpful.
- Maybe it's not actually as respectful and understanding as you originally thought.
- Maybe the way it's delivered works for others but you need a different format and can communicate that need to others.
- Maybe the feedback coming from people below you (reading into "on a podium") is different than from peers and you're internalizing it.
Whatever it is, I hope a break helps you reset and gives you space to figure it out!
Although my management and business skills were continuing to improve (and, I think, got to be quite strong), the loss of my technical competence did bother me. I ended up leaving and now I'm working as a CTO but with no team - more of an individual contributor, at a senior level in the company. I write code every day and over the past year my technical skills have mostly returned, and I've gotten to learn all sorts of exciting new stuff.
With that said, one of the biggest things I've learned is that, once you know how to write software, it's not that hard to get back into it. Learning Typescript has been straightforward. VS Code is a joy to use, but hey, Xcode was pretty great too. If having strong technical skills is important to you, then you have to change your focus and get back into it. But know that you can do this any time you want. On the other hand, if you value the skills of people management, reporting to a board, managing investments, etc., those are things that are hard AND valuable.
At the end of the day it's just about choices, you can't be great at everything. Good luck!
Best of luck from someone who's been there! With hindsight you'll be able to draw lessons for self improvement, and also realize just how much really was the fault of your environment, with nothing you could have done differently. Just take some time for yourself and learn what you can, and what to avoid in the future.
I think the "sense that you can change things", for which positivity is required, is the single most valuable asset that a company/team/whatever can have.
I think moving away makes more sense personally.
This is the sad truth at way too many orgs, even YC funded ones. Several times I have come in as a "highly respected CTO", and the things I end up doing that work are simply the same things the previous CTO was trying to do, but he/she wasn't able to get buy-in because of lack of respect from the non-technical parts of the org. Aggregating respect unfortunately goes a very long way.
1) Curate your resume and experience for years so that people will take your opinion very seriously (whether you deserve it or not)
2) When you know something is going to fail, call it out in advance with stakeholders and do whatever you can to pump the breaks and/or change course. If you have a lot of respect, you can use this to force an uncomfortable decision that someone without much respect might not have been able to push through.
3) Be VERY insistent in pushing your proposed mitigations when you know something is going to fail and know what will fix it. If you're sure, stake your career on it.
4) When people don't listen, and things fail because they didn't listen, in yearly review / feedback type things say "if only I had pushed harder for X, then Y might have been prevented" which is a nice way of saying "should have listened to me". Eventually everyone will just listen to you in the first place.
5) If you see the writing on the wall and no one is listening to you, exit while conditions are still favorable (I never actually do this, but I probably should).
6) When you are wrong, take responsibility, but only for the parts that are actually your fault. In reality the surface area of any one person's portion of blame in most situations is quite small anyway. Most decisions in orgs can be traced back to at least 4 people.
7) Make accurate predictions of failure if we don't take X course. When these come to fruition, you called it, when they don't, you still come off as very prepared for anything.
This can happen when the software group is seen as incapable, unresponsive, or even just slower than "business speed". I'd suggest talking to the individuals and their leadership (separately) to learn more about why they adopted X without talking to your department. You may well uncover missing or broken lines of communication, entrenched negative expectations ("it takes a month to get a simple DB query run, why would anything else be faster?"), and/or find processes so onerous that everyone tries to avoid them.
At the department level. Split them by probing for rifts between departments. Prioritize one group's project over another. Use department lack progress as dirt on that side's leadership. Get leader replaced and bring friendly face. Now both sides are friendly and open to better policies.
As a manager pretending to be CTO let them do what they want or you will be seen as the problem. Look for power shifts between departments and ally with the correct side. If your company wanted a strong CTO they would have hired or promoted someone. If you want to be in a position to be a strong CTO make powerful friends or get promoted and gather experience and win some awards.
Heh, the job I just left had a team like this.
I'd bring up ideas _for discussion_ all the time, at the very least to make my team members reconsider how we handle certain things. Even if my idea weren't the accepted one, we really had good reasons to improve our status quo. Yet just like what happened for you, when I'd call out some issue or situation the response from the team was that I misunderstood something or was crazy or etc. It gave me a lot of self-doubt, but I'd also bring up the issues to a senior engineer and he'd agree that usually my topics were worthy of at least some discussion since they had the potential to become improvements.
I'm in a non IT position right now and everybody is so stuck in the swamp everything is a 'no'. It now devolved into neverending politics. Mail fights and delays. A weird kind of bore and burn out.
Those that didn't have to work for it sit back and enjoy the paycheck while getting by with the minimum amount of work. To everyone involved work can just be a free payday, if the product fails they'll move elsewhere. Or if the product is too big to fail it's guaranteed anyways. Actual engineers are a rarity, and these companies don't like them because they point out how management has been milking the project.
Make something purely for yourself, just because you want it for yourself (whether an app or a website or a desktop program, a game, etc).
Design and code it how you want, focusing on making it work without obsessing about doing it the right way.
I think that will help you recapture the pure joy of coding.
Once you have recaptured that, then I think a lot of other stuff will kind of get back into the right perspective.
Maybe I need to mess around with some personal projects.
There are tons of remote options like BetterHelp where you can get an appointment quick without much hassle or commitment, so it's a pretty low threshold to give it a shot---that might be a good place to start. Good luck!
If you have a mentor or someone close that you really trust, I would really sit down with them and talk through this. Slumps are expected, and everyone has different ways to get out of them!
Also, this doesn't sound like burn out, but I could definitely be wrong.
I've seen two successful models of CTO that are "good developers:"
1. Knows the core tech of the company really well. There's some small bit of tech at your company that's legit an enabler of your growth. You should probably know it better than anybody. Maybe it's moved or changed or grown in the last 8 years, and you've lost touch a bit? It seems reasonable to carve out time to build something on your own, in the same space, using the new stuff. You probably have a better sense of what's important to get right than anybody else, so building a personal project with that tech on company time _is_ actually a great use of time.
2. Knows the system dependencies better than anybody else. This particularly applies if you have reliability woes or other systematic issues. You have a great position to ask other teams to educate you. Get a couple good devs from each team in a room, drop your ego, and have them teach you what they know in their domain. Do this across a bunch of teams. Some folks might find this irritating, but most folks will like the time to show off their work and share their worries.
Everybody is constrained by where they spend their time. If you want to go back to being a great IC ... you need a different job. Which it might be time for! But you can be technically great as a CTO, and I'm sure I've missed some other ways you can do it in the context of you "day job."
How do you escape the funk? Realize the funk is useful and normal, and it always was!
None of the comments here will give you the faith in yourself that you seek (that is not to say they are not good, or not beneficial). You are the only person who can give you that.
I utilize both micro and macro dosing and would recommend it wholeheartedly to anyone. If you or your family have had histories of serious psychotic disorders, bipolar, schizophrenia, etc... it can potentiate that - tread carefully - but otherwise I give the thumbs up.
Me too. I don't know. Force yourself into situations where it's sink or swim and that nobody is willing to step up to?
I don't since I have a family to support. If you're a CTO, that sounds like you've already made it.
- possibly your thoughts and feelings might be hormone-related. If male, consider getting T checked?
- optimistically, maybe you have built such a strong team that you doubt yourself in their context and it's time to move on :)
Its OK to not know something, CTO's and principal engineers are not gods of their trade but people who use the synergies presented to them. That is not an archive of man pages that you have produced for your minions, but the combined effort of everyone (technical) involved.
Realizing that you may lack a certain set of information is a perfect point to reach out to someone in your team, who does. You will see that the exact opposite of what you are expecting will happen: people will you value more because you can be reasoned with. See it this way: even if you could theoretically barely program, I wold wager that you have more tech skills than some CTOs the past has brought up. Really successfull ones too.
Even if noone other in your team has the answers to your problem, the solution is still communication. Either hire talent or use freelancers and consultants. That is what we do. But the result its still the same, it's your team that is facing the problem, not the problem facing the team.
On the risk of sounding a bit funny, but maybe you should consider taking a management course?
Why are you implementing features as a CTO? Isn't that what your team is for?
This has a lot of benefits: you can serve as their rubber duck and help solve their problems which feels great.
You can sanity check your thought process and conclusions. This will help assuage the doubt.
And it's a social connection which helps with anxiety.
Also, go easy on yourself. No one knows the 'right' answer. It's great to look for the best move but it's ok to make a bunch of merely really good moves, too. Allow yourself to accept the context under which your decisions are made.
Don't forget to give yourself space. You're CTO. Delegate the shit out of everything you can, even the stuff you're best at. Call it a growth opportunity for your team. But if you don't give yourself the space to make great decisions, everyone suffers. Avoid the 'busy-ness' trap at all costs. That's not your job.
The time I took off was restful, for sure, but the insecurity I felt was extreme. It took me another 3 months to get my groove back and just feel like, "no, you know what? I'm a decent programmer and I have earned the right to be here with the other devs. I'll catch up in my knowledge gap."
I always wondered how female programmers who go on mat leave cope with stepping away from it all for like a year.
If you asked me to reinvent the Linux kernel now, I would probably first say "I don't know anything about that, I'm not your guy", and if you were really insistent I'd give a huge number, like 10-15 years, with several disclaimers of "seriously, I don't know what I'm doing here, I'm pulling these numbers out of my ass".
Did I become a worse engineer in the last decade? No, I was just inexperienced ten years ago, and as a result I wasn't really able to differentiate "easy" and "hard" problems, and since I was a goofball (with too big of an ego at the time) I just assumed most projects were easy. Nowadays I have a much better handle on what I know and what I don't know, and as a result I find myself in doubt about things all the time. It's easy to get into a spiral of "I don't know to do this and omg I'm going to fuck it all up."
Writing the USB stack would probably take longer than the whole rest of the OS combined. (Though you'd be hard-pressed to write a USB stack in less than four months.)
That's why I'm saying that being unsure of yourself isn't necessarily a bad thing.