Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: I've lost faith in myself as a developer, how do I get it back?
318 points by cwitty88 on Dec 15, 2021 | hide | past | favorite | 235 comments
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?



Is it possible that you're not making the "right" moves because you're the CTO?

Leadership is hard and it's hard because you're making bayesian calculations on suboptimal choices. Almost by definition.

Say a Jr. dev has a problem that they can't solve. They kick it to an intermediate.

The intermediate can't solve it so they kick it up to a senior.

The senior can see a couple of solutions, but want's to run it past the architect.

The architect takes these options, weighs them against n number of considerations + the dev roadmap and sees strengths and weaknesses to all of them.

They package those pros and cons and brings them to you, the CTO to make a decision between these sub-optimal choices.

In this kind of environment EVERY move you make is going to be a little bit wrong. You just kind of have to minimize the wrongness


This is great insight. I'd like to offer a slight alternative for "You just kind of have to minimize the wrongness".

I think a CTO should have several mental models for making decisions. Minimizing wrongness is just one.

Some examples:

- Is this decision reversible?

- Does this choice allow my team to grow technically?

- Will this matter a year from now?

- Is this something I can buy instead of build?

- Is this a core competency that we should invest heavily in?

- Does this decision go against the company or your personal values?

- Is quick and dirty good enough for this?

There are several ways to orient the problem to help make a decision. But the OP is totally correct, this decisions will usually be made without all the data and with a lot of people looking at your decision.


Terrific checklist


Reminds me of this excerpt from an Obama interview:

> When problems reached him in the White House, he said, it was because they were unsolvable. He generally was being asked to choose between two bad options. “By definition, if it was an easily solvable problem, or even a modestly difficult but solvable problem, it would not reach me, because, by definition, somebody else would have solved it,” he said. “So the only decisions that came were the ones that were horrible and that didn’t have a good solution."


"So the only decisions that came were the ones that were horrible and that didn’t have a good solution."

This should probably be a must read for any wanna be presidents and leaders who are only after the power and glory.


So 100% of wannabes


This is only true where the system at least somewhat works. In other places you get police press conferences where they say "The president/governor has already given us orders to investigate the crime".


This is where I learned it, and it's why I'm much more forgiving of leaders than most people I know.

Which isn't to say they should be unaccountable. But these are people who make impossible choices all the time


How can it be "by definition"? Is the president defined as someone who picks unsolvable problems? Are the subordinates defined as people who solve every single solvable problem?


Ah I've resolved my long-standing question about this phrase. All this time I thought it was only used like in mathematics, but not so!

https://www.lexico.com/definition/by_definition


I, the OP used the phrase "almost by definition". And this has no quantitative backing, just my proselytizing.

The child comment about The President doesn't use the phrase "by definition" at all


If you are in an environment like this, you need to empower your engineers to make those choices: it will be more efficient, they'll feel better about the compromises they make themselves, they'll learn more from what happens, and you'll reduce the load on other people, like those seniors, architects and the CTO.


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.


> Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions

There's a cautionary tale buried here. Many seemingly Type 2 decisions are actually Type 1 decisions in disguise. Case in point, Amazon's decision to not allow warehouse workers to have their phones when working in the warehouse has resulted in the 6+ deaths and many more injuries that we saw in the tornado last Friday. Now there's no going back, and Amazon may (and should) be held accountable. Pretty grim for a seemingly Type 2 decision.


I don't know anything about the details of Amazon's policy in this instance or the specifics of what happened, but strictly going on what you wrote, I'm not sure that this tragic outcome necessarily means the decision was bad.

There are multiple ways of looking at any decision: perhaps, for example, employees with cellphones were more distracted and thus more prone to accidents.

My eleven-year-old daughter has no cellphone because we don't think being connected at her age is good for her (she also seems indifferent to having one, unlike my son, who is all about being connected). We also let her walk home from school on her own, and have for a couple of years now, because we believe she should be independent. I can imagine (although I try not to) situations in which those two decisions interplay and lead to a bad outcome, but I still think they are the right decisions for her.


This is nothing to do with one-way/two-way door decisions, you are conflating that concept with an understanding of "unintended consequences" in order to take a cheap shot at Amazon. Ordinarily I'd enjoy that as much as the next person, but this case is too ham-fisted to leave unchallenged.


You're missing the point. The point is that even the most mundane decisions can lead to irrevocable negative situations, so one should think about worst case scenarios with every decision, as engineers are regularly trained to. Classifying things as type 1 or type 2 decisions can create a blind spot, as it did in this situation in my humble opinion. In reality anything can become a one-way-door decision.

The "dunk" is a side effect. Amazon's decision making on this issue does a really good job of illustrating situations where you make a seemingly harmless decision that you feel you could revoke at any time, but things take a turn for the worse and regardless of your ability to revoke the decision, you can't revoke the damage it caused, the preventing of which is the whole purpose of having this system of type 1 vs type 2 in the first place. AKA the type 1 type 2 system is imperfect and can lead to miscalculations, like this. A more useful framework might be "can I prove, convincingly, that there is a 0% chance this decision will lead to irrevocable significant negative consequences, if so then it is type 2, otherwise type 1"


A proper 1 way door for your example would be to build warehouses in a way where cell phones don't work. Once people have died, you cannot make a change to allow cell phones quickly and cheaply. You're stuck with the warehouses, and either have to stop operations and build new ones, or accept the risk that more people will die

2 way doors aren't about making bad choices, they're about the response time and cost for when you identify that the choice was bad. You can make bad choices for 1 way and 2 way doors.

The best example I can think of for your argument is the flint water system. What looked like a 2 way door was actually a 1 way door, when the choice to switch water sources completely destroyed the pipes beyond usability, and any water flowing through the pipes would be contaminated, regardless of the source.

A 2 way door equivalent would stop being contaminated once they switched the water source back, even though people had drunk contaminated water


I understood you perfectly; I simply don't agree. Your model for decision-making bears no resemblance to reality at Amazon or anywhere else.


Not every quote about Bezos/Amazon is an opportunity for an off topic virtue signaling “dunk”.

If they are breaking the law lets prosecute them. If there is a law you want changed vote for a legislator to back it. If you don’t like them, don’t buy from them. This isn’t complicated.


It sounds like you’re saying that ethical/moral responsibility does not exist outside of what’s required by law in any given jurisdiction and the only venue for change is lobbying legislators? That it’s OK to do anything imaginable as long as it’s not explicitly prohibited by law?

If so I hope you reconsider one day.


no

I am saying hijacking a comment on decision making to leverage a tragedy in order to make some thoughtless “amazon bad” claim is kinda weird.

There is no right to your phone at work. Should there be? I dunno, probably not, but if you feel there should be then vote for it.

Did Amazon do “the right thing” I dunno but that reply isn’t bringing any clarity to that discussion either.

I agree we should have moral/ethical duties. Unfortunately society has degraded to moral relativism mixed with tribal absolutism. So what that would even mean these days is fraught


The lack of emergency alert was the main factor, not the cell phone policy just because cell phones have an alert system built in.


I accept all of your premises but disagree with your argument -- yes the lack of an emergency alert system is a factor, yes cell phones have a built-in alert system that could have handled this, and yes Amazon chose to suppress this alert system from working by denying employees access to their devices. They took away the only existing alert system and didn't replace it with anything. Garden variety negligent behavior leading to deaths.


Its not an argument and we came to the same conclusion. The case needs to focus on the lack of emergency system instead of getting thrown out unceremoniously by a judge who says "whats this got to do with cell phones"


Was that decision made by a small team? Maybe it was a top level decision?


We'll probably never know, but my guess is there will definitely be a symbolic firing over this.


I had never heard of these Type 1 or 2 Decisions, but this is absolutely where my head is at.

And it can be really hard for someone who loves to code to realize that this is primarily their job now. And they're always going to be kind of wrong


What GP means I think is the decisions that need to be made at CTO's level are generally going to be tough ones by definition. This is after empowering engineers etc... so easy ones are handled by them. Otherwise the CTO would be swamped.


This is inline with what I was thinking, but the Type 1 and 2 Decisions that a child comment outlines enriches my post in a way that I really appreciate


>You just kind of have to minimize the wrongness

And, if you can't figure out which is least-wrong, just make a decision, any decision. Don't become a roadblock. If the problem has already gone from junior->intermediate->senior->architect->cto it's already taken a whole lot of time and energy. It's software - you can fix almost anything (except certain security, reliability and financial controls) later if its wrong so making any decision is more important that making the optimal one.

I've definitely worked at startups where the CTO was the blocker for the longest time and we'd wait weeks on them when another senior people could have done the work immediately. Try to delegate and trust people as quickly as you can.


> just make a decision, any decision.

The nuance here is if you're making a decision that has a gross positive value, then you likely have a large number of "wrongness" choices that still result in a net positive. If you're not sure which of them to take then take any one that has a positive EROI (the ambiguity makes them all appear similar returns). Remember that EROI is marginal so even if you end up in a lossy situation _after_ the decision, so long as it's less loss than before you're net better off than you were.

If you're making a decision which all decisions seem to have a net negative EROI, then there is no opportunity at hand. Keep looking for a real opportunity.


> it's already taken a whole lot of time and energy. It's software - you can fix almost anything

Depending on the problem, it may be you need to experiment, research or call in an external expert. As a leader, you may need to make the call as to which approach but the execution itself should be handled by the problem owner.


^^^ This.

Remember, as CTO, your primary responsibility is making the tech deliver the bottom line sustainably. Not impress other devs.


There are some jokes that for most situations Supreme Court Justices aren't better than flipping a coin. Once a decision reaches there, it's so fundamentally ambiguous that it can't be resolved any better than flipping a coin.

*there are some things the supreme court does around consistency which aren't like this.


This is true for all responsible people, the way I tackle this is to try and predict the future.

Recently I had to implement interpolation in my game engine, before looking at that I tried laying out animations in memory and noticed a 3x speedup. So when it was time to decide I took the seemingly coward route of exporting animations in 120 FPS instead, hitting disk ×5 and RAM ×2 but saving CPU ×3.

Time will tell if this was the right choice, ie. will games render at >120FPS. The debt was moved from technical to energy saving, from complex to simple, from now to the future (since exporting in 120 FPS takes a little more time every animation that goes into the game)

I'm going to keep investing in low power because that is more guaranteed than everything else.


This reminds me of a Buffet'ism (if you will): "it is better to be approximately right than precisely wrong."

I heard it on a podcast, though I'm pretty sure he didn't coin the phrase.


I wouldn't be surprised if he coined it.

Admittedly, I'm a Buffet fan, so I think he can do anything.

But he is pretty famously a bit of a wordsmith


I highly recommend reading the Linux kernel management style guide at https://www.kernel.org/doc/html/latest/process/management-st....

It has this gem of a quote:

> It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always undo the damage later by backtracking. Suddenly, you get to be doubly managerial for making two inconsequential decisions - the wrong one and the right one.

It goes on to mention that most technical decisions fall inline as small changes and why.


This observation is profound, and also resonates with my experiences across different companies, some of which had highly mission critical / reliable systems.

I used to imagine from the outside that such places must have highly elaborate testing regimes, backup systems, and genius-level developers. However, my lived experience is that they're just really good / disciplined about reverting to the previous known good state and backtracking. Much like a source control system lets you undo a bad change and go back to a known good solution, they do that with their releases and entire system.

Some anti-patterns are "roll-forward" with a fix for a problem (if you failed to reason about the original change with the problem properly, how can you be confident that your "roll-forward" / hotfix / patch will work? Roll it back, try again in dev, roll forward again.

This also means avoiding changes that can't be rolled back (because they wrote data in a new format that the previous version doesn't understand) wherever possible (and it usually is).


Different domains, too: it comes up frequently in my - admittedly limited - experience with woodworking: _"Don't cut it 'til you need to cut it!"_.

There are some one-way doors (cutting a long piece of timber), or doors that inflict a big cost if you back-track through them (gluing a precisely cut joint), and you're well served by minimizing them and planning your operations to make sure those ones safe.

So, you 'sneak up' on a cut line incrementally rather than cut directly to it, allowing you to check fit as you go and ensure your final, precise cut is removing not a big, clumsy chunk but a tiny controllable shaving.


At $company, this is core to how decisions are made. There's no need to get stuck for an extended period of time on "two-way door" decisions; they can always be reverted. Inversely, decisions that cannot be reverted require due consideration. When there are multiple pending decisions, categorizing them into "one-way door" or "two-way door" decisions can help greatly.


Is $company a large Seattle-based ecommerce and cloud computing company?

Because that company talks about one way and two way doors a lot.


I also worked there and what I like about the phrasing in the quote above is that it surfaces the possibility of turning a one-way-door into a two-way-door.


Can you explain the last sentence of the quote? Seems ambiguous.


"Doubly managerial" is what threw me, but it's meant to be a little tongue in cheek. The linked source is specifically the Linux Kernel "Management" Style Guide, and is poking fun at management in general.

Another tongue in cheek line from the source is this:

> First off, I’d suggest buying “Seven Habits of Highly Effective People”, and NOT read it. Burn it, it’s a great symbolic gesture.


If you mean this:

> the wrong one and the right one.

The context comes right before it:

> if you were wrong (and you will be wrong), you can always undo the damage later by backtracking

Ie: do a (small) wrong, then do a (small) right to fix it. That's my reading of it anyway.


> Suddenly, you get to be doubly managerial for making two inconsequential decisions - the wrong one and the right one.

You get to wield the power of being the person who makes big decisions, some might say the finest decisions: decision 1 pick wrong path - decision 2 backtrack and pick correct path.

I guess in contrast to the person who wont decide - everyone has stood around in a meeting room staring at the senior manager fumbling with the most basic of choices.

Having the knowledge and conviction that it doesnt really matter anyway makes decision 1 appear decisive and strong. If it turns out to be wrong and you have to backtrack, you arrive in the correct place, and can take credit for correcting the course.


I think it means that when you are conducting your evaluation, you are doing more than just solving a technical problem.


This passage just helped me describe something I do and teach a lot at work: how to turn big decisions into small ones.


It does sound like burnout, and also like not being in the right environment (which contributes to burn out). I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about. Thankfully my previous job had been one where I had earned a lot of respect from my colleagues and managers, so I knew that I wasn't the problem, but even knowing that I found the doubt starting to creep in.

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.


Thanks for sharing your experience. I’m also going through similar issues with gaslighting at my job right now which I attribute to a few insecure colleagues and managers in a heavy tech debt laden environment. It’s done major damage to my self esteem lately. I was feeling very confident as a developer and tech lead until joining the team I’m on now. I’ve been constantly questioning myself lately even though my intuition, which I’ve normally trusted in, is telling me it’s not me, it’s my environment. It’s taught me a lot about my limits to take on constant streams of bullshit and I’m hoping to move on soon and heal the damage. I’m just hoping it’s something that doesn’t haunt me for years to come. What you shared gives me some hope!


It’s taught me a lot about my limits to take on constant streams of bullshit and I’m hoping to move on soon and heal the damage.

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 kinda figured I might be going through some burnout. I have thought about taking a sabbatical to try and recoup from it a bit.

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.


> 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!


I was CTO at a company and ended up managing a team of just under 20 developers and although I didn't feel the same way as you do right now, I did absolutely feel that my technical skills were becoming increasingly rusty. The Javascript revolution passed me by, Typescript was a mystery to me, all sorts of interesting things were happening in the cloud and I just wasn't hands-on with any of it.

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!


> I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about.

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.


Any tips or lessons learned on working with the non-technical folks? This is a struggle I am dealing with and am constantly trying to improve in. They want to do things their way, which might work okay but is inefficient and not in line with the technology goals of the company. Hard to wrangle them - they run off and do things without talking to me or the people in my department, not considering the plans technology has. I've been a CTO in the past and though I am not in that role now, we don't have a CTO and I am best suited so trying my best to fill in...


Unfortunately what has worked best in practice for me is:

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.


As a CEO you would do this.

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.


> They want to do things their way... Hard to wrangle them

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.


I've seen that happen at more than a few workplaces. It's a very interesting phenomenon, almost like a cultural helplessness that seeps into an environment. The crazy thing is that it only takes one or two people and everyone gets infected eventually. It seems you have to have a very, very strong personal fortitude to resist it.

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.


Yes but why? I mean why bother when it feels like trying to move rocks alone and even if you do you won't get recognition in any form. What can you do if the org just does not get it?

I think moving away makes more sense personally.


> I left. My new job has lots of tech debt, lots of processes that are broken, but when I propose changes people listen

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.


>I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about.

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.


What would drive me crazy is pointing out code that _clearly_ did not do what it was supposed to do and get back, at best, a shrug. I think I'm pretty open minded on most tech topics -- I started with PHP! If the code works I'm happy, everything else is gravy! -- but to have people insist that, no, this is fine and, yup, being on-call with services guaranteed to wake you up at 2AM at least once during your rotation and our stakeholders sending nasty grams once a month is just normal... crazy making.


I blame the terrible education system and software hiring practices. Graduating students don't know how to build software in a team, businesses do not properly onboard, and hiring practices are like an exam that has nothing to do with the work being done. Companies are becoming more averse to hiring those that actually learned software and didn't just fluff their resume with degrees and bootcamps because less engineers are doing the hiring.

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.


I left my first job for that reason, management had a complete inability to progress from "it works" to "it works well".


How are you the CTO and a developer? If you're coding features as the CTO your company must be really small so it doesn't really matter if the code isn't 'perfect'.

If the company is big enough where people have the time to call you out on shitty code and think they can do better - awesome! Let them code it, and you can focus on technical direction. Tell them what to do. Delegate. Let them write the code - it's what you're paying them for.

You can put your developer hat on at home and write code that automates the garage door at your new mansion.


This hits the nail on the head. I'm at the bottom of our management tier so I am still expected to do some programming. I feel schizophrenic at times because the mindset required for management and programming are very different. The demands are also very different.

I joke that if I only do programming in the 15 minutes between emails/team messages/calls/meetings/etc. The reality is that if I can't solve the problem in 15 minutes then I have to delegate it. Anything else is my ego getting in the way of getting the problem solved.


This and the comment below are super broad advice that you absolutely don't need to listen to.

I'm the CTO at 100+ person company and write code about 50% of the time.

Do the work you enjoy most. As long as customers are happy and you keep finding more of them, the rest will work itself out.


100+ person but how many devs? It doesn't feel reasonable for a CTO to be coding 50% of their time. Coding is usually the lowest impact / ROI activity one can have after having a couple of folks under them.


I can interpret your comment as "I'm a CTO who prefers to spend 50% of their time doing other things because they make me happy". It could be that your code and happiness level benefit the company more than CTO duties, but to me this situation seems like it would be suboptimal for most companies.


Are you sure your time is really best spent coding? Just because you are able to do it doesn’t mean it’s the best thing for your subordinates or company.


As CTO, you probably don't have the time and space, structurally, to be a good developer. You have things to do that aren't a single project or feature! So of course other developers will be better at "being a developer" than you, by some measures.

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."


I actually think that self-doubt is a sign that you're growing as a developer. If you had asked me how hard it would have been to write an OS kernel ten years ago, I probably would have said something like "Oh yeah, that's pretty hard, it would probably take me like four months to make Linux."

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."


A single-core single-tasking (or co-operative multitasking) OS kernel is fairly easy. You just need a memory allocator, syscalls, maybe some virtual memory or process isolation (as a treat), and a basic display driver.

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 might be true (I don't know, I've never done it), but my point is that I would have thought that I could implement something as large as Linux or macOS in a few months, when in reality that's certainly not true even with my ~decade of experience, let alone when I first dropped out of college in 2012.


There's no reason you shouldn't have been able to. Programming basic things like an operating system shouldn't be as hard as it is. (Honestly, programming an entire OS is easier than programming within existing systems, at this point, for many applications – but only if you can cope with bare-bones serial I/O.)


You're completely missing his point. He was simply using "programming operating systems" as an example. His point still stands regardless of how easy you think something is or should be.


If your goal is to produce Linux, you've picked the wrong goal; just use Linux! But back when computers were simpler, in the months April – August 1991, one absolutely could make an OS kernel where things “seem to work” in four months.


Ok, you're very clever. Replace "building an OS" with "proving the Goldbach hypothesis" or something. I was just giving an example of what I thought was a challenging project. Clearly for you it wouldn't be challenging.


You’ve described the Dunning-Kruger effect: https://en.wikipedia.org/wiki/Dunning–Kruger_effect


Yep! I'm aware of that.

That's why I'm saying that being unsure of yourself isn't necessarily a bad thing.


CTO and developer separate into distinct roles as a company grows.

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.


The company is growing in all facets. We added 17 engineers this year when we previously had a total team of like 10.

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.


I would similarly commend you for the awareness and bravery to step down, but I would offer two notes here:

> 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 :)


You likely know what is best for you, but let me offer the counter argument. Your company's dev resources are growing. You are questioning yourself as a developer. You probably know more about your company's stack than anyone. You are CTO.

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.


When I first saw your post, my reaction was: CTO after only 4 years of work experience? I've been coding for 30 years now, working for 20, and only in the last 5-6 years have I felt capable of playing that role.

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.


It sounds like if you were to stay on as CTO you should consider delegating some more of the management, not just the tech. Who in your team can step up to support you? A CTO with 20+ people should be doing low-touch development if at all.

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.


That is a courageous choice as others have said. You are ultimately doing the right thing for yourself and others. There is possibly an opportunity in the transition if you are staying with the company to set yourself up with some dev work that will let you recover. Depending on circumstances, a passive handover puts you at risk of landing in an awkward spot.


That sounds like a good decision. I would greatly respect someone that I saw making this call, far more than if they tried to struggle through and did damage to their own careers or others. Best of luck to you.


>I'm actually stepping down as CTO and becoming a developer again because I am not a good manager, that I know for sure.

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.


Unfortunately, you may need to let go of your tech work, or shunt it over to "nights and weekends."

I was a manager for 25 years, and one thing that I learned, was to never put myself into the critical path. I could do tech projects, but they needed to be "nice to have on the side" projects.

Management requires that we work on interrupt. We can't have that sweet "fugue," that makes us productive developers.

What I did, was work on a lot of open-source stuff, on the side. I didn't have deadlines, and it allowed me to keep my "tech chops" up.

Since leaving that job, I tossed the management stuff into the skip, and have concentrated 100% on tech work. I love it.

I'm a damn good engineer. I get a hell of a lot done, at awesome quality levels, in very little time, but I also don't particularly care whether or not anyone co-signs my work.

Also, I'm not a jargonaut. Lots of folks like to sneer at people like me, because we suck at Buzzword Bingo.


It's possible still to do some real coding as CTO. One thing I like about Stripe is that the leadership will make sure to take a week or so each year to ship a real feature and then write up all the little pain points that they experienced and ensure they are addressed - it helps quite a lot with developer productivity.


> Management requires that we work on interrupt. We can't have that sweet "fugue," that makes us productive developers.

Thank you for this. My boss left in October and I have not been dealing well with the influx of things on my plate even though I have the time in terms of hours, and that explains why: The items I took over from her are directly opposing what I need to do my job.

Well. It doesn't fix it, but it's validating, I guess.


This article popped up here a while ago and I think about it a lot in context to this exact question: https://zapier.com/blog/actual-impostors-dont-get-impostor-s...

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.


> 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.

It seems that you already have the answer.

You know that there are times that you are right and that other people are wrong, and perhaps this occurs often enough that you are being inadvertently gaslit.

If you're CTO and you are being called out to this extent, then you might want to consider finding another company or stepping down to a senior engineering role. I've never been a CTO or have worked closely with one, but my impression is that a CTO gets some sort of respect and final say around things technical. There's a mismatch somewhere here. Other people aren't always right, no matter how reasonable they may seem. There has been plenty of times in my career where I've pointed out objectively counterproductive development practices and have been told that I was wrong because reasons, and sometimes I've totally noped out of those clients/companies for that reason. Unless you really need the next paycheck that badly, life's too short for the mental agony of doing things that are nonsensical.

Although I hope you also can consider whether your ideas are actually the right ones. Sometimes I didn't learn until years later how right someone was when they criticized or disagreed with my engineering decisions.


> 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.

I think you need to find some good mentors; and/or find some good people in your organization that you can talk about these issues with.

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

Assuming you're working in a team setting, you need to direct the people who will call you out into planning to make sure that things are done the "right" way. And, then ask yourself, why aren't these people writing the coding guide, picking the patterns, writing the design, or reviewing such work? Why aren't you delegating to them?

One big mistake that I see is a general lack of mentorship when someone is "leading" without at least decade under their belt. You might be the smartest person in the room, but without experience, you're going to make mistakes that are "obvious" to anyone who's been in this field for 10+ years.


Athletes who have a long career will sometimes take time out to reinvent their game. So do some software developers.

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.


Sometimes coding just sounds like the worst thing I could possibly do. I do enjoy thinking about writing some code but when I sit down all enthusiasm goes out the door. Maybe I need to tinker with something in the real world tangentially related to code and that will help.


Or just find some hobby that has nothing to do with software at all.

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.


Out of curiosity, why are you still coding as the Chief Technology Officer?

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?


So when that sometimes happen don't force yourself into it. I'd watch some tutorial on YouTube and try to replicate that, watch videos from all angles: game development, frontend tools, 3D graphics, databases, protocols, talks from conferences... whatever comes into your focus.

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.


Have you been involved in the code this whole time, or just getting back into it?


You aren't ANYTHING. You are not your job or your skills.

Trust your gut. You've been busy with other things, and you have fallen behind as a developer. That doesn't mean you are worthless or unable to improve again. It just means you need to be humble and have a plan to improve as a coder.

The only way to improve consistently I have seen is to seek feedback from peers. Seek out a trusted colleague and ask to pair program for a while. Submit PRs early and often, and get early feedback.

I know a lot of people who would never admit they are struggling, and just say everyone else is the problem.


This seems like less of a development problem and more of a self confidence problem. You should have a session with a therapist, there is probably a deeper cause of this in your life and you'd be better off trying to figure out that than finding a bandaid that HN could provide.

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!


Besides therapist, a 'personal development coach' could also work.


> software developer for about 12 years, the last 8 of which I have been the CTO

As others have pointed out, you can't really be CTO and a software developer unless you're at a tiny company (like 3 people tiny) and you claim that you're "growing like crazy" which implies that you couldn't have been CTO at a small company for long.

This then means that you've been a software developer for 12 - 8 = 4 years. You're not and never have been a very senior IC, and there's nothing wrong with that if you're in a CTO role. You're probably not a bad developer, but you don't have the experience and skills of a really great senior IC. The skills required of a good CTO have almost nothing in common with those of a strong, senior IC. The only reason it's useful for CTOs to have developer experience is to help communication, but nobody looks up to their CTO for advice on solving day-to-day software problems.

My guess is that if you're worried about your developer skills you might be lagging in some of your CTO duties (totally possible I'm wrong here). I would first make sure you're providing the high level leadership and support of that role. It's also possible that you don't really want to be CTO, if you want to be developer you can easily find a place where you can transition into an IC role.

Overall it sounds like you should reflect a bit on what you want, where you currently are, and how to get to where you want to be. Do you want to be a great CTO? do you want to be a great developer? or is there something else you're looking for?


Ask your teammates. Communicate. The role of the CTO grows at the stage were you are immensly but the hardest switch you have to make is to manage people and not projects. Because, you know you hired people for the projects.

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?


Serious answer: drugs, specifically psychedelics like Psilocybin. There is a reason use of these medicines is often called "tripping" - it will take you to a new place and offer you new perspectives.

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've been super interested in trying Psilocybin as an long term anti-depressant. Looking forward to more research coming out on this topic.


It's a fungus that literally grows on cow shit - what have you got to lose? Humanity have been using this for thousands of years. Nothing to be afraid of! (tl;dr You don't need to wait for the right research to appear on your doorstep in order to give it a shot)

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.


It is interesting to see what you have described as part of your role as CTO. I'm a CTO as well, and of a relatively medium sized company (~600 people). I'm also an avid developer and engineer, but those developer and engineer skills are primarily tasked with exploring new technologies. The CTO role really does vary a lot from company to company, and CEO and CEO. I prefer the approach of a CTO being very technical, but not focused on things like active code production. The technical part comes into play when you are thinking about the future, and trying to make decisions that will influence the company many years down the road. Any focus that is narrow enough to get 'called out' right away would be an indicator of too narrow of a focus.

In a way the biggest fear for a CTO is getting called out 3 or 4 years down the road for problems in the core direction you set. It happens, and will happen, and we all work to make those events as rare as possible.


I'm in the same position. 12 years software dev. 5 years CTO. Company grew double each year. I had teams under me.

I found that I had lost my developer experience over the years and I didn't feel like a good CTO. I figured I was burnt out and started to not care about the work but couldn't bring myself to give myself a rest or sort it out. I quit last week.


You need to find other smart people in a similar place but with no skin in your game and rubber duck with them about what you're thinking about.

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.


If you've been CTO for 8 years, there is a good chance that it's time for you to delegate more of the technical work to some team leads, while you focus on the wider needs of the company. Depending on how large the company is, your main task right now might be to better integrate the work of the tech team with the work of the marketing team, or inventory team, or content team. I've been writing about this issue a lot lately, see:

"Should top managers focus on their peers or on those who they lead?"

https://demodexio.substack.com/p/should-top-managers-focus-o...

Many newly promoted managers stay focused on the work they used to do, but fail to give enough attention to the other parts of the business, with which they need to learn about and integrate with.


Pick a new-to-you technology you're interested in, do File/New Project... on it, and just build something. Give yourself permission to be a beginner again. Build something that no one else will see, but that you'll regain your confidence with by proving to yourself that you're still capable of learning and growing. You'll see that something that took you 20 hours to do in week 1-2 will take you 20 minutes in week 8.

And remember: this is art, not science. We all make artistic decisions about how to do things in programming all day (we pretend it's science or engineering... it's not) and you will, too. Give yourself permission to do things how you want to, it's all just a learning opportunity.

I did this when I turned 40 after years of being an architect... it refreshed my love for coding.


Its so hard to untangle everything that might be going on here(based on 3-4 sentences), but at the end of the day if you know you are a decent developer and you have been able to hold down a CTO role for this long, you are worthy of confidence in yourself. Not every decision you make will be a good one(and that is absolutely ok, if people working with you can't understand that, it is on them), but one of the worst things you can do is to stop making impactful decisions out of fear that some of them will not have great outcomes.

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.


Yeah, I've been in a similar situation. One ugly side about being a developer I find is that if I stay away from the practice of coding for even like 3 or 4 months I feel rusty or I feel like you've missed out on a lot. I remember when I took off 4 months and then started doubting my moves.

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.


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

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.


I would recommend reconnecting with the fun of being a developer.

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.


I do miss hacking away at stuff just for the joy of it. I'm a little OCD so I have to be mindful about not attempting perfection as I go.

Maybe I need to mess around with some personal projects.


Do Advent of Code. It's the first time I've been drawn into extracurricular programming in quite some time. It's been fun. They're bite sized problems and you're only committed as far as you want to be, and no later than Christmas.


I would encourage you not to think of this as a personal, internal issue. We are obligate social animals.

This self-doubt isn't happening in a vacuum. You haven't gone into depth here (and that's fine) but it sounds like a lack of psychological safety. And even if you are the CTO you cannot create a supportive environment by yourself.

Who around you is calling out what you do, or making you feel (even subtly) that what you're doing is shitty?

(and yes, if that's the environment, it absolutely contributes to burnout)

Imagine you have opinionated or senior developers, maybe with a tiny chip on their shoulder - they know better than their idiot boss! And you're not the sort of person who wants to ride roughshod over them. Their opinion matters to you.

There are absolutely ways they could advocate for their own views and express disagreement without making you feel stupid.

If anything like this sounds right (just spitballing after all), I don't know what to do without more details. Gonna be hard to say "be nice" without sounding like "don't tell me I'm wrong." But not impossible.

Wishing you the best.


As CTO, your primary responsibility is leadership, so assuming you have other development staff, your Principle Engineer/Senior Architect/Lead Developer (or multiples of these in a larger organization) should be providing you with technical options. Your job should be to weight the pros and cons of each within a larger perspective of resource impacts and return on investment. The technical solutioning should be delegated and then affirmed by your direction.

If the CTO title is more ceremonial (or your organization is very small) and you are actual performing the role of the most senior developer, know that there is no “right” solution to any software development task. Any working solution outweighs any theoretical optimal solution. The only real metric that matters is that each time you make a decision that it is better than the last one; where better is an amalgamation of (personnel * knowledge * skills * metrics ) / time available.


You're a CTO.

By definition, if what you're doing is working, it's the right way. There's nobody higher up the chain to tell you otherwise.

If it's not hitting the goals you're setting for yourself, you'll need to determine if the goals are unrealistic or if the approach you're taking to reach them is unrealistic (as CTO, that's often more of the job than writing the actual code).

It's hard to be at the top; it often feels like "working without a net." I changed companies to avoid that feeling when I was younger, and it's possible that's the right move. But if you stick it out, I just want to share that "working without a net" feeling only diminishes if you build a net for yourself (in the form of process you can use to determine if anything is working).


The highest level of mastery is realizing how much you don't know and that nobody knows anything compared to what there is to know.

Beyond the feeling of unease that comes from the above realization, who is the voice the back of your mind who is critical of your code or your technical decisions? Is it an old voice from childhood, a parent or a teacher, or is it current, your peers for example? These voices are sometimes triggered by events going on in your life, work related or not.

Is it really your code or is it that you don't work in a supportive environment? Perhaps someone is gunning for your job and being subtly critical in ways that are getting to you.

You might want to look at "egoless programming" and work on getting your ego out of your code and into the competitive workplace where it is more relevant.


Maybe it's a small company / tech team, but I have to wonder if you are experiencing these feelings because as CTO, your time as a developer is really in the past. What I mean here is - sure, in some companies the CTO is still a hands-on-keyboard role, but over time, your role as a hands-on developer should begin to diminish and your responsibility becomes to delegate those duties to people in your organization you trust. Your responsibilities and skill set move away from low-level technical. If that upsets you, then I'd question perhaps you'd be happier in an individual contributor role and not in a Cx0 / managerial role. That isn't to say that a CTO role isn't technical, but that it is operating at a different level.


- maybe do a fun, small coding side project

- 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 :)


Get help. Someone to talk to. Maybe a therapist but probably a coach.

I'd suggest looking up a local independent coach. Maybe ask around for references. If you can get the company to pay for it, great (should be worth it to them). Otherwise pay for it yourself.

You have thought about this a lot, and come to a big realization. You need an outside sounding board to help you think through the implications and figure out next steps. A coach seems like a great fit because they are aimed at personal development, whereas a therapist is for fixibg things. It doesn't sound like you need fixing.

(Saying this because of personal experience with coaches)


You could try focussing on other facets of the tech industry, rather than the one you are currently surrounded with.

Meet-ups, hackathons etc are good ways to stay up to date on diverse topics & letting your brain work on new stuff instead.


I miss hackathons, those are fun because the entire purpose is that you're just slamming shit together to make something work in a short amount of time. In the early days that is basically how our entire codebase was.


Some good advice here. One thing you may want to consider is that CTO of $x MM company and CTO of $100x MM company are two completely different roles. As different as engineer vs manager.

If you haven't actively adapted over the last 8 years, this may just be the result of being in a job you don't like. Whereas regular-exec work might be a lot of management, architecture decisions, etc., high-level-exec work is more pure politics, storytelling, and resource allocation.

There's a reason a lot of startups replace their sr execs every 10x-100x growth period or so.


This rings true.. I was a CTO of a startup growing to $10x M company, and now am the CTO of an $100x M company, and the envelope of work is very very different.

I spend far more time thinking about, researching about, and developing about what we will do in 2-3 years, instead of 2-3 months.


Being a CTO and doing dev creates a ton of cognitive dissonance that takes a lot of mental energy to process. I would look for mentors who can talk you down off the ledge when needed, and help you establish habbits and rituals to better separate the areas of concern in your day to day life.

Also appreciate that most thoughtful engineers are their own worst enemy. Its a sign that you're good that you even care. Find a way to taper back your own self-criticisms because after a certain point they are inaccurate and not helpful.


I've been thinking about how in much of software engineering there is no "right" way to do anything. The only "wrong" decisions are those made without adequately considering all the tradeoffs or made without much thought at all. I would say your role as CTO is not to know everything and make unambiguously "correct" decisions all the time. It's to make sure the right questions are being asked and considered when technical decisions are made.


Well, look at the positive side, as a CTO you probably don't have much time to code anyway.

Jokes 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've been CTO since the beginning but it was almost all coding in the early days. Now it is much more of a management role. I actually just started the process of stepping down and going back to being a developer because I dislike the management side of things a lot.

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.


> 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"

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.


One thing to keep in mind with respect to that - often when teams grow you get more ivory tower types. Not that everyone wants to build an ivory tower, but you do get a lot of in-between. One thing to keep in mind about why the code was the way it was - it was designed that way to grow the company fast and to get customers. Nearly all companies that start that growth will face the inevitable - let's rebuild all of this from scratch. It doesn't mean your original contributions were worthless - no one would be working there if that was true.

In the end you may move more towards explaining to people how the company operates, how the data is processed and keep that going.


Oh I have been in a similar position myself. Was a single dev in a startup and I needed to cut corners. I implemented everything. From embedded controllers to user interface and I even used code that some students wrote as a proof of concept to save time. Codebase was a mess. It worked in the end, but barely and maintenance was horrible.

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 not in a startup, but you should comfortable answering/acknowledging something along the lines of we needed it working quickly, and this did the job for x amount of time based on the time available at the required throughput.

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.


Yea that is about right. Given the knowledge and requests I had at the time I solved it the best way I knew how. No one opts for worse it just happens from time-to-time given business constraints.

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 assume you built things in questionable ways because as you said, the company was growing like crazy and there was no time to “do things right”. It just had to work. It sounds like you did a great job if the company is currently doing well.

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.


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.


>we built things in questionable ways

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!


Humility is very important for coding (most things, really). Everyone writes "questionable" or "ugly" code, so it's important to accept that as much in yourself as you do for others. Think about what you would say to someone else in your position: would you be as critical of them as you are of yourself?

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.


My first though though when you say these things is: I wonder what the company culture is like? The environment could be toxic if your feeling so much doubt.

I think being a CTO brings it's own unique challenges, perspectives and context. You were a developer. Your not exactly one now and that has to be considered. For one you have context that developers don't and they may not understand that. It also depends on the specific situation. Good code, 'right way', it often just translates to "my definition of right or good". Lots of subjectivity to software development, as weird as that sometimes feels. Lots of ego and ego is a problem.

In my experience a group of developers can believe something is right very strongly and be completely wrong about it and that really sucks because we're social animals and, for better or worst, concensus is often at play in decision making.

No idea how to fix your specific issue but I think it requires openness and sharing and accepting that different people have different opinions on what's correct and everyone has to accept that it differs from person to person. Did you want to share anything specific? Not sure if it'll help but it might give you more insights to get a set of different opinions from outside your usual circle.


I highly recommend Kent Beck's keynote talk from RailsConf 2015: https://www.youtube.com/watch?v=aApmOZwdPqA (or if you prefer, a more recent blog post with a similar message): https://medium.com/@kentbeck_7670/accountability-in-software.... Software development is hard, and it's easy to do things the wrong way. The thing to do is figure out how to do things that give you confidence you're doing things the right way.

In some ways, it can look bad for someone in leadership, like a CTO, to get called out for not doing things the right way. At the same time though, if you and the leadership in your company have hired the right engineers working with you, even if you are the CTO hopefully people working with you know more about specific areas than you do, and as CTO you can help make sure that things fit together. So what if you get feedback on how to do things better? You as CTO have a chance to set an example to others on the team for how to receive feedback constructively.


Maybe it's burnout, but those hipsters that will call you out for not doing things the "right" way, will one day fly to the next flower. You'll probably stay and do the work, come rain or shine. Just stop worrying too much, the fact alone that you worry about doing shitty stuff or called out puts you in another category than those who really do shitty stuff. Btw, humans do shitty stuff all the time, it's our thing.


My sympathies. You are merely suffering from work overload and a little-bit of burnout + "Imposter Syndrome".

First off, DO NOT RESIGN from your post of CTO. Your Experience, Knowledge and Seniority is what got you that role, so no need to give up something which you have earned and which can be made more manageable by changing perspectives, work habits and learning.

The basic problem is that as you went up the career ladder you took up more load without shedding any. A CTO does not have to be a Super-Duper Developer (there is simply not enough time) but needs to know enough to understand the product/service. The CTO is a "Technology Strategist" i.e one who can understand Technology deeply, see how it can affect Domains/Markets and how to marry the two. You need to be somebody who can connect the dots and push towards a goal. The view is overarching and not local i.e. you "see the forest and not just the trees".

So dial down your desire to be a "nitty-gritty Developer", understand broadly what every role (IC, Tech. Lead, Architect etc.) entails, interact with them all and only take responsibility for the "Global Company Strategy".


Hey OP, sounds like we're in a similar boat in terms of role, tenure, experience, and (guessing from username) age. My email's in my profile, if you want to trade notes or just vent feel free to reach out.

I think you're getting so much terrible advice in this thread, from everyone attacking you for writing code. You should be writing more code if that's what you like to do. I spend about two thirds of my time writing and reviewing code, take the lead new features (core and experimental), fix bugs, and generally work on whatever I find the most fun and think will be the most useful for customers. You can do the same and still lead a very large and fast growing company. This idea that as a leader you should abstain from doing real work is nonsense and results in bad leaders.

If you find yourself stressed about the code you write adhering to everyone else's standards, I'd suggest 1) not worrying about everyone else (easy to say / hard to do), or 2) finding a commercially valid excuse to make a new repo and try some fun ideas out there. If the ideas are good, incorporate them into the main codebase and get back to what you do best.


Technical Managers move to Non-technical over time.

Here is another secret, no one has the right way to develop. There are many development styles and some produce better short term or long term results.

Unelegant code that works might be just the thing until more robust, better architected, unit tested code takes its place it all comes down to the purpose. A small one off hacked together solution for on boarding might be better than spending three months to "get it right " it all depends on risk appetite, project standards, and the scenario.

Don't act like you know better if you don't. Listen to other developers ideas, they might have input you haven't thought of.

Always Be Learning, not as catchy as always be closing, but the path of a developer is a path not a destination. You can always make progress.

Fear of failure or being called out as a fraud shouldn't stop you. Remember everyone makes mistakes, no one is perfect, lots developers think they write the best code in their shop, and would critique your code even if you objectively were the best developer of all time.

Learn the industry standards as you can and shore up your weaknesses with good underlings that will help you learn.


If you're a CTO, why are you building out features, if I may ask? Shouldn't most of that be delegated to devs under you?

In any case, it sounds like you might need to try to find a community of folks to help mentor you, and act as sanity checks? At least, that's my thought.

Though with everything that's happened in the last two years, it may just be burnout, in which case rest is probably the best approach.


The truth is you aren't a developer any more, you are a CTO. You are responsible for making key technology decisions on behalf of your business, and for building a team of people under you who can successfully execute your technical vision. The way to get out of your funk is to let go of your previous existence as a developer and to embrace the very weighty challenges of your new role.


Maybe the company simply don’t have a well defined product and business model?

Some places try to create solutions for things that don’t have a problem. Being caught in the middle of such a requirement chain will make you doubt yourself. Especially after you realize it is a bullshit idea to begin with, yet still have to keep a smile on, both in front of your subordinates and your investors.


As a CTO myself, I can commiserate. I'm still a decent developer but I'm also a decent project manager, systems architect, software architect, tester, business analyst, software engineer and sysadmin, not only because I have my hands in all of these roles now but also because I've done these roles in my career. I'm also a decent salesman, service delivery manager, business strategist, etc.

Unfortunately, when you step into a CTO role, skills-wise, you have to become a generalist to do your job better.

If you're losing faith in yourself because you feel your technical capabilities is diminishing and so is your perceived value to the organization, I fully understand. You need to reevaluate what your value in your role. Is it important that you're the best developer? To me, no. As others have pointed out, your job is to make the better decision in a sea of decisions; I say better and not best because sometimes the best decision is not the right decision for the business.


Lots of great answers so far. Consider also that a CTO of a 5 person, 15 person, 30 person, and 100+ person (etc) company is not the same role, despite having the same title. So I think if you start at 5 and stay CTO as it grows, it is pretty natural to feel like you are always fighting to adapt -- you are. And likewise if the role begins to outgrow you, that's par for the course. In general when I think of CTO I don't think of them as programmers really, but more as leaders who play a role in recruiting, landing deals, setting (broad) technical direction and thinking years out. E.g. "Should we build or buy this thing that will take 2 years to do, based on the market, our competition, and who we have at the company." I think its natural to lose your core development skills. You can always get them back if you want. But that will be a different job of course :)

Good luck!


I saw two videos related to this that gave me pause to think.

First was that when you are higher up the chain, you should not be making decisions on small stuff. You should be delegating to the smartest people that report to you.

Second, in the executive level, you should be focused on strategy and identifying industry trends, not on doing day to day grunt work.


Can you share the both urls?


I recommend you build a Java-based logging utility that is secure.


When you’re a ~linear developer (regardless of seniority level) working on tasks and issues without time limits, you only know your own craft and seal every hole the boat may theoretically have. But when you see the whole business picture, and how dynamic it is, or when that is pushed down to you chaotically and unfiltered, i.e. not reworded as your CTO+ would do carefully, the anxiety of vagueness and indecision may come in. E.g. there is a feature which has to be done “yesterday” and “will probably live for only few months”, so it’s obvious to just hack it into the code. But as a tech guy you know all the implications of this way in the future. But as a CTO or a guy who sees more, you also feel this “yesterday need”. These two facts usually mix together into shitty trade-offs, shitty side being pushed from other CxOs.

If this seems to be the case, the solution is to care less of that chaos and care more of your developer’s craft, which you seem to still have more affinity to. It is your role. Push the anxiety back to where it belongs by doing/planning things the right-most possible way and negotiating it to the forces which drive it ahead “like crazy”.

There is a balance between growing like crazy and turning all limbs into cancerous tumors. You may find peace of mind in finding it and messaging it back to where imbalances originate from.

I would ask myself in this positon what do I want as a pro (hard one), whose responsibilities I take on me without profiting from it (not only money-wise), make it clear what will happen to me, to the company and to the next guy if I just leave, what are both good and bad sides of how things work now, think which points of that list should be fixed, which should be added, in the circumstances, and evaluate possible outcomes. I mean not which I can “live with” today, but which should [not] be there strategically. And finally, I’d detect the source(s) of trouble and message them publicly-directly about the structured issues from that board. It’s a huge reflective/collective work, which would serve good both me and the company.


I've reached different performance levels in different environments. It's a bit embarrassing to see how the environment impacts me. When I feel the confidence and encouragement of others, my capacities increase and I out perform, and when I don't, I sort of 'shut down.' I suspect it is because I grew up in a verbally abusive household and I go numb. That is what it is, and experience has shown me I can't just snap my fingers and get over it. It's okay to require a positive environment. It's okay to change jobs to get it. BTW I have reached high engineer ranks at FANGs. I have also noticed that when the environment is negative and I am working hard, I reach burnout more quickly.


A counter argument if I may -

When I was CTO I built the MVP and coded at first. Then after adding engineers we started shifting the architecture to their designs (because it's important to allow people to be creative and own things, right?) and I started feeling like a sub-par engineer, not creating sophisticated code as they did.

Well, turns out they overcomplicated things, focused on complex problems rather than end-to-end feature delivery, and waisted a lot of time rebuilding things that wete better (albite simpler) in my MVP.

For me, the takeaway is - trust yourself. You know best.

It's not the same lesson for everyone, some people are too controlling, but it seems you and I are closer to the other end of the spectrum.


If you're "CTO of a company that is growing like crazy" then you shouldn't be writing code anymore. You need to develop your management skills. If you can't do that, then it's time to step aside.


I try and say this as much as I can, and I’m going to say it here: therapy is great. I highly recommend it, just take some time to find a therapist you get on well with.

This is in addition to the other advice here, not instead of.


This is called executive wisdom. You are seeing things clearly now. Most ideas are bad. Most execution is sloppy. Just because you can does not mean you should. Your primary job is to kill all ideas except the one thing you are absolutely certain of. Do that one thing. Over-do it. Then do it again. Be certain that there is no possible way that anybody could do it better.

Edit: I probably should have said to kill all projects/features/goals that you are not absolutely certain of. Ideas for achieving the same objective in a different way, are probably good risks.


I think you have a couple choices:

1. Stop developing. Then you don't have to feel judged for dev work.

2. Stop CTOing. Then you're "just a developer" and you can go back to doing work as a team, where your own personal opinions or decisions should not override those of the team. Being "wrong" is fine, because whatever decision the team comes to is "right", and you all cooperate together to accomplish the shared goal, right or wrong.

3. Continue to be a CTO, continue to write code, but go to therapy and find out the source of your fear, then figure out how to cope with it.


Whenever I experience this anxiety, I have learned that the cure is almost always better feedback.

If I'm worried about the performance of my software, but I don't know which things to optimize, I need to use a profiler.

If I'm worried that my code changes introduce bugs, I need tests.

If I'm worried that a design isn't the best set of trade-offs, I need to share it with people whose judgement I trust and get their feedback.

I'm not a manager, so I don't know exactly what feedback looks like at your level, but I'd suggest involving more of your team and collaborating on decisions more.


I had a CTO in your same situation. His remedy was to schedule more meetings.


> 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.

Why are you implementing features as a CTO? Isn't that what your team is for?


That sounds somewhat like "Imposter Syndrome".

All of us have to combat that Syndrome at some time or other. For many of us, it strikes more than once.

In my case, I've had it strike in several of my 'professions': Pharmacist, Programmer, Pilot.

I'm beginning to suspect that 'Imposter Syndrome' is a normal 'Rite of Passage' - on moving from mid-level to a higher-than-normal level of expertise in that particular field. You get the 'Am I good enough to match those others who are already in the upper echelons of the field?' doubts.


> 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.

You will likely get called out whichever way you make the decision by people tunnel visioning on one side of the coin. Getting called out doesn't mean the decision was wrong. Your goal should not be that no one calls you out. Rather it should be to be able to say: Yeah I took that drawback into account.

> CTO of a company that is growing like crazy.

Well if the company is growing like crazy then you must be doing a lot of things right?


Walk 10,000 steps a day. As you walk, listen to various podcasts that touch (not direct-hit) on your workspaces.

What you'll get:

- Brand new ideas (new learning)

- Confirmation of ideas you already hold, but weren't 100% on

- Knowledge of some ideas you held that were wrong (without anyone else knowing!)

Also set aside a little time to do some 'fun coding'. Maybe Go or Erlang or C#. Something that's a little close to the metal, but not mind-numbingly difficult to get going with.

Good Luck. Given a little time spent right, I'm sure you'll be bursting with confidence in no time.


There's a STTNG episode or two where it becomes known that Captain Picard is just kinda winging it, while looking confident.

Regarding large software systems there almost never one right answer. At times we need to make decisions without perfect knowledge. Some portion of those decisions will be suboptimal of course. Whereby we make more decisions to hopefully improve the outcome. It's the nature of the problem.

Perhaps you have "decision fatigue?" Sounds like a nice vacation is in order.


I definitely have decision fatigue. I decided to step down to get it off of my plate.


Beeing a bit self critical is a skill and i think it's actually good for a CTO. Defenitely better than the opposite.

Maybe search on some colleagues where you can discuss technical things at eye level. You beeing CTO doesn't mean you have to know everything better (imo, dependent on the company culture it may backfire).

Maybe it's something unrelated and you are just a bit depressive. I can easily imagine that happens to a lot of people with all the reduced social contacts due to covid....


What I can feel is that you aren't able/wanting to keep up with the rapidly evolving technologies. Maybe CTO and success has put you in a comfort zone. Maybe after being CTO of a crazy growth company you feel you've made it. Maybe what you're doing doesn't fire you up anymore. Maybe you just got lucky and opportunistically became CTO. You can either continue this stable, secure life and slowly decay or change course, whatever that may be.


Or the person had an epiphany that the only things rapidly changing are ephemeral, and that feels futile?


Firstly, I think its excellent and of great benefit that you are a CTO that has experienced what your fellow developers do.

However, you're the CTO and your role realistically shouldn't be developing, but it should be weighing up the decisions your team is making as THEY develop, building connections and looking at the forward strategy.

It sounds to me that you made the move into the CTO role, without fully making the break with what you used to do in your previous role as a developer.


Can be anything.

But from my own experience: it might have to do with lack of energy.

It sounds like you are responsible for the decisions you make. If you don't have a lot of energy you don't have energy to deal with possible bad outcomes. That's when you start to overthink your decisions to protect you from energy loss in case you made the wrong choice.

So check your energy levels.

And if the responsibility is too much for you be honest about it. Involve others to make the decision.


I'm going through something similar at a much smaller scale (startup CTO of 2 years, not much growth). It's been enough to make me want to quit software engineering altogether. It sucks.

At least your company is growing and you know that you are a decent developer.

Maybe you can take a sabbatical. Talk to your partner if you are on good terms. Make sure to explore your options.

Hope you find a way to move forward and regain your confidence.


Do you discuss your technical decisions with your peers? That might give you some validation. I chat all the time with people about what techs to use.


Yea we definitely discuss tech decisions as a group. We didn't in the past though and so some of them are poor decisions that have deep implications in the codebase. We're trying to unwind them now. Maybe that is leading to the feelings I have been having.


I don't just mean with your current org, I mean with your wider network of people who understand the issues. With outsiders you get people who aren't invested in the same way, yet have done similar work.


This is a smart brain thinking: I am inadequate!

This is 100% normal: you are comparing yourself to the world nowadays and, since you read HN, to many real brave people (I am scared myself too ahahahah).

My advice is to cool down and tell to yourself: "developing is not rocket science"... but practice, a lot of practice (as in any art) is needed: no practice, no speed.. no result, which is as in any field. :)

do not be too hard on youself


You might call in a consultant as a "technical therapist", to talk over your decisions and issues, technical challenges in the company, etc. That's a lot of what they do. If you're feeling lack of confidence, does that mean things have been going wrong? Alternatively maybe there are some engineers in your company who you can trust having those sorts of conversations with.


> 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

Fix your expectations. Perfect things don't exists. Don't get trap into the idea of perfectionism. In retrospective, everything will look like "not doing the right thing", don't take that personally, that's how retrospective works.


I think if you have been CTO for 8 years and its growing like crazy (and your growing your team) your doing a good job as CTO - at that team size its not really the job of CTO to make individual contributions - the job is more to find new talent for the team, to nurture existing talent on the team, and to make sure that good technical decisions are being made.


I don't have advice or answers to any of your questions. I don't know if your situation will get better or worse. I appreciate the humility implicit in your question, and it makes me feel a little better about related things I'm dealing with in my own life. Thank you for that, and I'm rooting for you to get where you want to be.


Does the company have product market fit?

If not, don't worry. If you do, don't worry. Perfection is the enemy of good enough.

You want to hire developers who will take your vision and turn it into good code even if that means rewriting your code. And every developer will rewrite your code to make it their own. They will also always complain about your code.


It is so much easier being an engineer than being responsible for engineering direction.

The first group is afforded the "ask for forgiveness not permission" mantra, while the latter is left with "fall on the sword".

This leads to generally higher pressure and less feedback since you are kinda sorta pioneering and not just following hand-me-down instructions.


You need to slow down and enjoy life. I too had a burnt out, now partially recovered but still it’s difficult times.


not having blind faith in yourself is a really good thing because it makes you humble and willing to learn. Shitty work isn’t the end of the story because you can improve it over time. Doubting your decisions helps you avoid fooling yourself.

How do you escape the funk? Realize the funk is useful and normal, and it always was!


You have to accept uncertainty and mistakes. When you look at super successful people like Musk, Jobs or Gates they all have a long list of major screw ups but they just kept plugging along and did the best they could. If you expect yourself to always make perfect decisions you will lose your mind over time.


thanks for asking, i feel you.

few months ago i went through a similar self-trust downturn. i had a nice salary, complete decision making freedom, great team, booming market.. i was getting the job done, but i felt like shit and couldn't trust myself with anything..

now i'm in a process of figuring things out. i'm not there yet, but it turned out the problem we were solving stopped being interesting to me. that made me rely on "best practices" and i stopped being creative. couldn't come up with brilliant/scary shit to do, everything was so predictable..

if you have shitty problems to solve, or not interesting to you personally, you won't be able to engage.

if developing makes you happy, then find problems worth solving in the first place. some time off helps, find some scary things to do. satisfaction is on the other side.


My initial reaction is you’re a CTO not a developer. Perhaps you’re trying to play both - something got to give if that’s the case given the leadership overhead.

As others have mentioned- hire the best and empower them. If being a developer is your passion then perhaps you should consider giving up the CTO role.


I think if you were not at that company, someone else would be making the mistakes. I think the fact that you are still there after 12 years, and consider your decisions so critically says that you are good at what you do.

As a Disney princess once said: "Let it go".

Forgetting is just as critical a skill as remembering.


There is no right way. Anyone who calls you out on doing things the wrong way, is wrong. There are better ways.

Except, if you're not listening at all to suggestions from colleagues, then you may be doing things the wrong way. Or when the code is just failing at doing its task.


Maybe there are just too many options these days? Every day a zillion new technologies seem to appear that you are supposed to use, so that you are "doing it right". While most of them may be cool, YAGNI still applies.


Are you keeping yourself physically fit?

Are you taking care of your body?

Are you sleeping well?

Are you eating well?

Also, consider checking your hormones. Age and stress will move your thoughts in this direction. There are ways to counteract though.

Mind and body are inseparable, one influences the other.


There are as many ways as there are developers.

Dealing with infinite unknowns is just part of the package, the reason most can't cope, the reason we're paid relatively insane amounts for what we do.

So say my 35 years in the trenches at least...


Build little things that work, with no economic pressure. Join a Open Source project and build something people could need or love. Not big, just a little feature, a little help.

Seek contact to those using your software.


This sounds a lot like burn out or depression to me (I’m not an expert on that field!). Get yourself checked. It happens to the best, especially now during pandemia.

Read about „imposter syndrome“ and „decision fatigue“.


Dude, resign and take some time out. Don’t fret, plenty of opportunities.


It has been said elsewhere in this thread, but dude, you are management, not talent.

Keep abreast of stuff and the winds of technological change, but hire people to code and get them to make the outcome you want.


What is hot today is cold tomorrow... everyone uses google to code... everyone copies and pastes stuff from stackoverflow... github copilot and autocomplete are life savers...

stop being hard on yourself


I'm not a CTO but what I want from a CTO is to set a direction and make choices that we all follow. E.g. programming languages used, update frequency, SaaS products used, etc etc


From a distance, it is very hard to diagnose, but try to sleep more, do more sports, take a holiday (at least 2 weeks). Al of those can help re-wire and put things into perspective.


You’re the cto. Lean on your senior engineers and ask sanity questions. That’s your job as cto, not to come with all the answers.

Save your design and coding for your home projects for fun.


Being a great software developer is all about being comfortable with self-doubt.

If you're not for a prolonged period of time, it's likely burnout.


"Do something, even if it's wrong." - eighty year-old gentleman at a poker table when people would think for too long.


You’re a c-suite exec. You’re supposed to pawn that work off on someone else and then apply your cynicism to them.


If you’re really the CTO of a company that is “growing like crazy”, you probably shouldn’t be doing any coding.


Imposter syndrome (n): 1. delusions of mediocrity.

I've been faking imposter syndrome for the past thirty years.


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

Who do you fear it´s going to do this?


Build something for yourself. Doesn't if it's shitty. Just build something.


Maybe it's just the impostor syndrome in disguise?


professionally executed K E T A M I N therapy.


I've felt the same thing this year.


Do you suffer from “imposter syndrome”?


pick a single platform to build expertise in. start coding. don't change the platform.


You're having an emotional problem, not a technical one. Therefore you need to ask a therapist, not other developers.


Peer support is really undervalued in the modern world. Empathy and advice from people similar to oneself can be just as, if not more, healing as professional support, for certain situations.


It may be undervalued. What's important is that it's not as good as professional support, even if it's better than people think.

A good therapist is better at empathy and asking the right questions than a peer. Peers may have more domain knowledge and familiarity with the situation, but this is only important for juniors. A CTO can make their own good choices once they identify the problem.


Sorry to be blunt, but you are rightly sensing futility. You've been working on something for 8 years, when the entire software industry lifecycle is only 2-3 years. So nearly every problem your company has solved was probably solved 6 years ago in open source.

I'm only saying this because I worked on a video game for 11 years. Finally got it released, at the cost of a falling out with my best friend and business partner, and we never recovered our friendship in the same way. This stuff can be brutal.

If you're a CTO in name only, then you're probably also sensing that investment in different people or tools like #nocode could have bigger returns than more code. But maybe that doesn't sound good to investors, so you keep doubling down on the current approach.

I went through a massive burnout in 2018 and lost my job in 2019. The stress combined with too much alcohol and gym time finally just burned me out. Humans aren't meant to live under continuous stress for years on end. It was like having a stroke. I lost all decision-making and problem-solving ability and could barely get out of bed for 6 months. Then the rona hit.

There's hope though, because I made a full recovery. Here's what I did, YMMV:

* https://www.depression-chat-rooms.org

* Split and subdivided my tasks to their most granular level in todo lists

* Executed the tasks at a different time or day to exercise executive function

* Tackled the low-hanging fruit instead of the hardest thing first

* Prioritized my physical needs over a job after I found the smoking gun, that gut health affects serotonin and can be sent out of whack by common foods like dairy, tree nuts like almonds, legumes and nightshades (B vitamins, digestive enzymes, kefir, psyllium husk capsules, spinach, iodine, etc, talk to a nutritionist or eastern medicine/Ayurvedic specialist)

* Dedicated myself to service (donated plasma, jumped to help others in need, vocalized that I was there for people)

* Found ADHD TikTok

* Set boundaries (most important of all?)

* Tried something completely different for awhile (handyman for another friend during the summer of 2020) - AND/OR - Worked on my communication skills

That last one might be hard to do, so if you can't take a break from your job, I'd recommend opening a dialog with the people around you. Being more transparent with my supervisor/boss at my current job has done wonders. It turns out that many of the people who antagonized me over the years were actually terrified that I was going to run away and leave them hanging. We're working through a tremendous amount of projection and anxiety as a society. So it might help to flip the situation from "what's wrong with me?" to "how can I help?" because the change in perspective might reveal the issues that your subconscious mind is warning you about.

In the end, it was all worth it, and I'm so much happier and more resilient now for the experience. But I can't lie, I still struggle some days with the continuous nature of it. All I think about pretty much all of the time now is how much I just want a break. But, a bigger percentage of my time now goes to my personal development goals (bought an electric car that I'm going to take full solarpunk to drive for free) so I use mantras and meditation and envisioning a better future to push through the tough mornings.

Hope something in this helps!


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!


Probably the first thing that should be acknowledged here that being good CTO isn't the same as being a good dev.

I'm not a CTO and never have been, so feel free to completely disregard my advise, but from what I've observed being a good CTO is far more about communicating effectively with the rest of the org, understanding business requirements and ensuring the development team is equipped to solve problems than being a good dev. To some extent you also need to be available to unblock devs when there are key decisions that need to made at a higher level.

In a smaller company you might need to wear multiple hats from time to time, but when you're acting as a CTO your job isn't to be a good dev and to do things the right way, but to ensure you have the right devs and architects in your team so they can tell you the right way to solve problems. The most you should be doing is approving and guiding their decisions. If you feel you have something to offer as a dev then by all means, share your opinion with the team, but your not there to be a dev, you're there to be a CTO.

It sounds like you're taking too much on honestly. You can't be expected to know everything or be an expert on everything technical problem that comes your way -- that's not what a CTO does. A CTO just needs to have a solid high-level understanding about how things come together and delegate everything else.

I think first you need to decide if you want to be a full-time CTO or a CTO who is also a developer. If you're going to continue to be a developer while being CTO then you'll probably just need to accept you're statistically unlikely to be the best developer on the team to solve every problem and therefore from time to time you're going to do things wrong and you're going to need to seek help and feedback from other devs.

For what it's worth a small-medium sized company I used to work for had a CTO who was also a dev (he was the first dev), but by the time I joined the team he was also the weakest dev there. Thing is, he acknowledged that and that's why we were there. He picked up a few dev tasks from time to time where he could and when he had time, but otherwise he would trust us to tell him the right way to solve problems and let us get on with it. He was a great CTO in my opinion, not because of his dev skills, but because he trusted us and gave us the resources we needed to get our jobs done. There were many occasions I needed help from other devs on the team or even external resources and he would always make sure that help was available to me so I could do my job well. That's your primary role as CTO in my opinion. You're not suppose to be a good dev, you're just suppose to ensure you have a team of great devs who have everything they need to be great devs.


> 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.


Yeah, that's was my first thought. But perhaps it's not quite as simple as that.

I've been a developer for almost 4 decades now. My confidence in myself ebbs and flows. But the pattern is highly predictable: when I develop something that works, it flows, and when an idea doesn't work out it ebbs.

When I start any project I always think it's a cracker of an approach, of course. Sometimes that's true, something it's not.

What that means is "Build something" doesn't always work the first time. But if you keep building things you will accumulate hits, and eventually confidence that brings.


TLDR; To be confident, be humble, help others, appreciate failure, and know you'll never be an expert.

Long form:

The one (or last?) time I felt this way was when I had just stepped down as CTO of a well funded company I co-founded.

I can say today that the reasons for stepping down had little to do with my competence, though I didn't feel that way at the time. In truth, it was 2007, and my co-founder and I realized that we were in for a very long stretch of no income, and a short runway, and that the best thing to do was to essentially go on standby.

Still, my confidence took a hit.

I took about a month off, which didn't really help change that feeling. I enjoyed the time off, and it was good for me in general, but it didn't change how I felt about my abilities.

Eventually I decided to do whatever I could to reduce any doubts I had about my competence. I started teaching people how to write code, which meant I really had to make sure that I knew what I was talking about. Teaching helped fill in a lot of gaps I didn't know I had, but also helped me see that I knew what I was doing, at least enough to teach others.

I didn't stop at teaching how to write code though. I started consulting, and managed to find gigs that let me help engineering teams communicate better, and taught those same teams how to have more robust practices around code changes, releases, failures, debugging, code reviews, etc. All the other non-coding stuff every coder needs to be good at.

It took years, but eventually it got really difficult to feel like I didn't know what I was doing. It was clear I knew enough to be effective.

I learned another pretty important thing during that time:

I'm not an expert. No one is. The people who say they are don't yet realize what they don't know.

Admitting I'm not an expert does a few things: it allows me to fail and learn, and to be grateful for what I gain when I do. I don't pretend like I'm a beginner that can't function without stackoverflow. I just leave room for the possibility that there are often better ways to do something. I've learned that shutting the doors to those possibilities is a sure fire way of feel incompetent.

Being humble and ok failing makes all the difference. If someone doesn't like my approach, that's fine. Rather than defend my approach at all costs, I explain the goal, define constraints, and reduce any friction towards hearing how to improve the idea. If after talking it out my idea was still the right way to go I make sure to express gratitude for the feedback.

While trying to "get back", a friend of mine who recently lost his fight with cancer, who's leadership abilities and incredible software development skills were something I still hold up as my "end goal", often said: "It's always good to be humble, and almost always better to be humbled."

I try to optimize what I do around that idea. Having a baseline of "there's always more to learn" just makes things better and easier.

It also helps me get stuff done. It helps me have good relationships with people I work with. If someone doubts a decision I've made, my default mode is to assume they're correct. They often are correct, and I grow. Sometimes they're wrong, and it gives me an opportunity to be humble and help them grow with me. Either way, no energy is spent defending an idea because my ego says I need to. Energy is only ever spent on improving my skills and the skills of teams I lead or work with.


Make something yourself, on your own. Show yourself that you've still got it.


I'm also a developer,to made sideprojects that make me happy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: