[HN Gopher] Ask HN: I've lost faith in myself as a developer, ho...
___________________________________________________________________
Ask HN: I've lost faith in myself as a developer, how do I get it
back?
I've been a software developer for about 12 years, the last 8 of
which I have been the CTO of a company that is growing like crazy.
Recently I have been doubting every move that I make and have lost
all faith in myself as a developer. When I look at a new feature I
just think that I will make it shitty or get called out on not
doing things the "right" way. The thing is, I know I'm a decent
developer but I find myself doubting every single decision that I
make. Is this burn out? How can I get out of this funk and move on?
Author : cwitty88
Score : 235 points
Date : 2021-12-15 15:57 UTC (7 hours ago)
| clavalle wrote:
| 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.
| optymizer wrote:
| 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.
| myohmy wrote:
| 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.
| faldore wrote:
| It is a young startup; the technical cofounder needs to code,
| there is nobody else to do it yet.
| lordnacho wrote:
| 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.
| cwitty88 wrote:
| 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.
| lordnacho wrote:
| 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.
| MeinBlutIstBlau wrote:
| It just sounds to me like a lack of confidence when interacting
| with other people. You're aware you're a good developer. But you
| issue you say very clearly is that "..I will make it shitty"
| implying other people will perceive it that way or "get called
| out" which again, implies what other people believe.
|
| You need to accept that you cannot always win. You will fail at
| some point in life. Accept the fact that you could lose your job
| tomorrow. Then, don't worry about it. Wing it and almost
| everything you do. I always tell myself "well they haven't fired
| me yet so I'm clearly doing something right." Although you're in
| a CTO position so it's definitely different. But the concept
| applies. Brush shoulders with people who matter. Make them like
| you or stay on their good sides. Take work off their hands to the
| point they feel like they need you. Give yourself a purpose.
| steve76 wrote:
| Someone asks for a request, say nothing, and start work on it. If
| they keep pestering you, ignore the request and pick one minor
| fault of their's, like "Write a quick unit test and meet me in
| like 5 minutes ... ... ... It takes you more than 5 minutes to
| write a unit test?"
|
| Keep working on it in quiet. Work on it with the sole objective
| of assigning it to other people. Divide the work in half, than
| half again, than half again, so eighths. And start organizing
| github issues to assign to people.
|
| When they come back again and ask, fire it up and show them
| without saying a word. Show them the problem you are stuck on
| without saying anything. I found software is like that. It's one
| stucked grain in the gears, and once that's fixed a floodgate of
| progress opens.
|
| Never compromise on your personal integrity and standards. Types,
| unit testing, zero downtime blue green deploys, databse
| migrations.
|
| Also I found serious projects get ugly quick. The demos are
| always bland and hide known problems. Big real projects it's like
| really cooking with heat. It takes a day to build and test. I
| want that big municipal level financing behind it.
| randomNumber7 wrote:
| 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....
| dredmorbius wrote:
| Imposter syndrome (n): 1. delusions of mediocrity.
|
| I've been faking imposter syndrome for the past thirty years.
| poulsbohemian wrote:
| 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.
| colangelod wrote:
| 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.
| diarmuidking wrote:
| 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.
| bgroat wrote:
| 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
| lr4444lr wrote:
| ^^^ This.
|
| Remember, as CTO, your primary responsibility is making the
| tech deliver the bottom line sustainably. Not impress other
| devs.
| randito wrote:
| 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.
| alasdair_ wrote:
| >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.
| vorpalhex wrote:
| > 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.
| maerF0x0 wrote:
| > 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.
| incompleteCode wrote:
| 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.
| necovek wrote:
| 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.
| anon2020dot00 wrote:
| 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.
| sam0x17 wrote:
| > 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.
| AstroDogCatcher wrote:
| 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.
| sam0x17 wrote:
| 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"
| pkaye wrote:
| Was that decision made by a small team? Maybe it was a
| top level decision?
| sam0x17 wrote:
| We'll probably never know, but my guess is there will
| definitely be a symbolic firing over this.
| pcmoney wrote:
| 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.
| adriand wrote:
| 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.
| vmception wrote:
| The lack of emergency alert was the main factor, not the
| cell phone policy just because cell phones have an alert
| system built in.
| sam0x17 wrote:
| 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.
| vmception wrote:
| 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"
| bgroat wrote:
| 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
| hawk_ wrote:
| 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.
| bgroat wrote:
| 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
| gcmac wrote:
| 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."
| hutzlibu wrote:
| "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.
| jpmoral wrote:
| 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".
| Kinrany wrote:
| You're having an emotional problem, not a technical one.
| Therefore you need to ask a therapist, not other developers.
| nitrogen wrote:
| 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.
| Tarucho wrote:
| > get called out on not doing things the "right" way
|
| Who do you fear it's going to do this?
| throwbynight38 wrote:
| 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.
| sponaugle wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| gwbas1c wrote:
| > 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.
| bionhoward wrote:
| 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!
| ChrisMarshallNY wrote:
| 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.
| alasdair_ wrote:
| 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.
| Mezzie wrote:
| > 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.
| ninjaa wrote:
| 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.
| jkingsbery wrote:
| 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.
| kkjjkgjjgg wrote:
| 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.
| belowmedian wrote:
| 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.
| DarthNebo wrote:
| 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.
| cwitty88 wrote:
| 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.
| curiousllama wrote:
| 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.
| sponaugle wrote:
| 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.
| anyonecancode wrote:
| 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.
| sam0x17 wrote:
| > 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.
| heurist wrote:
| 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...
| sam0x17 wrote:
| 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.
| spacemadness wrote:
| 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!
| nitrogen wrote:
| _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.
| [deleted]
| spike021 wrote:
| >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.
| anyonecancode wrote:
| 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.
| cwitty88 wrote:
| 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.
| adriand wrote:
| 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!
| adjkant wrote:
| > 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!
| throwawayninja wrote:
| I left my first job for that reason, management had a complete
| inability to progress from "it works" to "it works well".
| agumonkey wrote:
| > 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.
| danielvaughn wrote:
| 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.
| solididiot wrote:
| 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.
| drbojingle wrote:
| 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.
| PicassoCTs wrote:
| 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.
| fdschoeneman wrote:
| 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.
| mwattsun wrote:
| 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.
| yumaikas wrote:
| 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.
| jn78 wrote:
| 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.
| pier25 wrote:
| Build something for yourself. Doesn't if it's shitty. Just build
| something.
| baskethead wrote:
| 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.
| munificent wrote:
| 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.
| RcouF1uZ4gsC wrote:
| 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.
| cwitty88 wrote:
| 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.
| rjbwork wrote:
| 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.
| shadowgovt wrote:
| 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).
| raxxorrax wrote:
| 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...
| cwitty88 wrote:
| 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.
| almostkorean wrote:
| 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.
| shrimp_emoji wrote:
| >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!
| computronus wrote:
| 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.
| kevinventullo wrote:
| 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.
| blt wrote:
| > _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.
| lief79 wrote:
| 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.
| cwitty88 wrote:
| 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 :).
| rhacker wrote:
| 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.
| raxxorrax wrote:
| 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".
| sleepysysadmin wrote:
| I recommend you build a Java-based logging utility that is
| secure.
| [deleted]
| ramsundhar20 wrote:
| You need to slow down and enjoy life. I too had a burnt out, now
| partially recovered but still it's difficult times.
| throwaway81523 wrote:
| 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.
| nscalf wrote:
| 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!
| rocqua wrote:
| Besides therapist, a 'personal development coach' could also
| work.
| sabhiram wrote:
| 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.
| Metricon wrote:
| 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.
| lkrubner wrote:
| 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.
| codr7 wrote:
| 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...
| whalesalad wrote:
| 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.
| cwitty88 wrote:
| I've been super interested in trying Psilocybin as an long term
| anti-depressant. Looking forward to more research coming out on
| this topic.
| whalesalad wrote:
| 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.
| racl101 wrote:
| 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.
| rajacombinator wrote:
| If you're really the CTO of a company that is "growing like
| crazy", you probably shouldn't be doing any coding.
| mym1990 wrote:
| 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.
| tmaly wrote:
| 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.
| rocqua wrote:
| 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)
| giantg2 wrote:
| "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.
| kaetemi wrote:
| 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.
| jdthedisciple wrote:
| Maybe it's just the impostor syndrome in disguise?
| trjordan wrote:
| 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."
| tombert wrote:
| 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."
| wizzwizz4 wrote:
| 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.)
| tombert wrote:
| 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.
| wizzwizz4 wrote:
| 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.)
| latexr wrote:
| You've described the Dunning-Kruger effect:
| https://en.wikipedia.org/wiki/Dunning-Kruger_effect
| tombert wrote:
| Yep! I'm aware of that.
|
| That's why I'm saying that being unsure of yourself isn't
| necessarily a bad thing.
| dokem wrote:
| 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.
| kypro wrote:
| 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.
| blueside wrote:
| I had a CTO in your same situation. His remedy was to schedule
| more meetings.
| cleandreams wrote:
| 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.
| Eighth wrote:
| 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.
| honkycat wrote:
| 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.
| SBArbeit wrote:
| 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.
| PaulHoule wrote:
| 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.
| cwitty88 wrote:
| 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.
| PaulHoule wrote:
| 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.
| tiborsaas wrote:
| 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.
| johnmarcus wrote:
| 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?
| sdwr wrote:
| Have you been involved in the code this whole time, or just
| getting back into it?
| tmp_anon_22 wrote:
| 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.
| tailspin2019 wrote:
| > 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!
| BrazzVuvuzela wrote:
| Make something yourself, on your own. Show yourself that you've
| still got it.
| coyotespike wrote:
| 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.
| maxk42 wrote:
| 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.
| justinzollars wrote:
| easy. Build something.
| nickjj wrote:
| 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.
| tacostakohashi wrote:
| 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).
| caminante wrote:
| Can you explain the last sentence of the quote? Seems
| ambiguous.
| raffraffraff wrote:
| 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.
| achillesheels wrote:
| I think it means that when you are conducting your
| evaluation, you are doing more than just solving a technical
| problem.
| jonchurch_ wrote:
| "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.
| crehn wrote:
| 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.
| mabbo wrote:
| Is $company a large Seattle-based ecommerce and cloud
| computing company?
|
| Because that company talks about one way and two way doors a
| lot.
| spir wrote:
| - 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 :)
| marsdepinski wrote:
| pick a single platform to build expertise in. start coding. don't
| change the platform.
| im3w1l wrote:
| > 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?
| Donckele wrote:
| Dude, resign and take some time out. Don't fret, plenty of
| opportunities.
| throwaway52423 wrote:
| 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.
| globalise83 wrote:
| 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.
| time_to_smile wrote:
| > 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?
| daanlo wrote:
| 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.
| ravenstine wrote:
| > 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.
| tdrdt wrote:
| 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.
| Too wrote:
| 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.
| mixmastamyk wrote:
| 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.
| zackmorris wrote:
| 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!
| cwitty88 wrote:
| 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!
| jhoelzel wrote:
| 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?
| readme wrote:
| You're a c-suite exec. You're supposed to pawn that work off on
| someone else and then apply your cynicism to them.
| loopsody wrote:
| professionally executed K E T A M I N therapy.
| onelastjob wrote:
| "Do something, even if it's wrong." - eighty year-old gentleman
| at a poker table when people would think for too long.
| spaetzleesser wrote:
| 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.
| sjg007 wrote:
| 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.
| andix wrote:
| 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".
| cloverich wrote:
| 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!
| pezzana wrote:
| > 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?
| PragmaticPulp wrote:
| 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.
| cwitty88 wrote:
| 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.
| adjkant wrote:
| 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 :)
| zerkten wrote:
| 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.
| radicalbyte wrote:
| 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.
| ximeng wrote:
| 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.
| sjostrom7 wrote:
| 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.
| jmann99999 wrote:
| 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.
___________________________________________________________________
(page generated 2021-12-15 23:01 UTC)