Work isn't everything. If you start working on your health, it will improve your mood and outlook. My guess is, you have an introverted personality and occasional feelings of isolation are just part of it. Try to accept it rather than fix it, because you might find that if you did have peers, that would have its challenges too.
Re eating/getting healthier,
1) food: this guy Rip is truly a lifechanger (esp if since you're in the zone when it would be smart to look after your heart: https://mealplanner.plantstrong.com/
2) Lose weight (this approach might be appealing to your engineer'y instinct): https://www.fourmilab.ch/hackdiet/
3) Exercise:
- Warm up (DO THESE): https://www.youtube.com/watch?v=-QWyyHfARNI
- Try to get through a round of this w/ good form + then try to do 2, 3, etc: https://www.youtube.com/watch?v=XTSIqbuZC0Y&t=369s
I don't have any career advice for you, leaving is one option but consider that it would great for you to "skill-up" the people around you so when you leave it isn't like they lost their Golden-Boii, but rather bow out like a Bob Iger at Disney & leave them with a glorious future blah blah
I had the exact same experience in my first job, where I was one of the least experienced developers and I wasn't even remotely the smartest one there.
However, I was working smarter than everyone else. For example, I was the only one that had adopted a "proper" IDE (IntelliJ IDEA). I was the only one using the source control the way it was supposed to be used. I was the only one using scripts to automate the gruntwork. Etc...
I could be told about a bug and the function name it was in and be done fixing it in under a minute. Literally just the "global semantic search" feature of the the IDE saved me hours of time compared to everyone else. Incremental builds saved me another hour. Automated tests running in the background eliminated an hour of manual testing.
Hilariously, the reason I leaned on the tools so heavily was that I felt like I wasn't good enough to navigate the codebase without the assistance of an IDE.
The end result was that I could run circles around everyone else. Like you, I compared the checkins per week and I was #1 by far. Literally more fixes per unit time than everyone else combined.
This should be a lesson for everyone here who thinks that they are smart, or experienced, or "senior":
- Your typing speed is not your velocity. It doesn't matter how good you are with VI or Emacs if you take hours to complete a task that a purpose-built IDE lets a junior developer finish in a minute.
- Tooling outside of the editor matters. Incremental builds matter. Automated tests matter. Telemetry from production matters.
- Focusing on features while there are open bugs is a guaranteed catastrophe. You will have to fix the bugs sooner or later anyway. You can fix them right now, or you'll have to compensate for them while adding features... and then fix them later, after having wasted your own time.
Etc...
The codebase I was working on was Java, server and client.
I actually learned a lot from that job! I stayed just long enough to see how they do everything so I can then do the opposite in my career. I purposefully quit before I ran the risk of being infected by their attitude.
Random examples of the madness that went on in that place:
- They created a custom database engine in Java that used millions of tiny flat files to store the data. The reasoning was that Oracle was too expensive. They then had to license Oracle anyway because they couldn't generate the ad-hoc reports their customers wanted out of their own DB engine.
Lesson learned: Always use common, popular CoTS OLTP DBMS products. Don't make a DB engine unless the DB engine is your only product.
- No transaction capability in the custom DB. The logic for writing data to the DB was... hilarious.
Lesson learned: never try to "emulate" transactions. Always use the built-in transaction idioms of the underlying system.
- Deadlocks, live-locks, data corruption, and even thread leaks were the norm, not the exception. The server would only start up successfully 2 out of 3 times at best.
Lesson learned #1: Multi-threaded code is either proved to be correct mathematically, or it is Wrong with a capital W. There is zero wiggle room on this.
Lesson learned #2: Use the best quality[1] multi-threading libraries for their "primitives" such as bounded producer-consumer queues. Never try to hand roll these yourself for any reason, ever. Just don't.
Lesson learned #3: If you code is riddled with critical crash and correctness bugs, you'll never know if the change you just made has introduced a new bug.
- Only full compiles would work (by default).
Lesson learned: a 30 minute delay in the type-build-run-debug cycle is productivity-killing madness. This is the most important metric to optimise for anyone in charge of a dev team. Pretty much nothing matters more than this, because it multiplies out everything else. Buggy code? Now it's minimum 30 minutes to fix a bug. Slow code? Any optimisation had better be worth the 30 minute wait! Behind on features? 30 minutes minimum for the smallest change. Etc...
- Ignoring naming errors, such as functions being named as if it does one thing but it actually does something unrelated. Similarly, there were tons of typos in identifiers.
Lesson learned: IDEs with refactoring capability were invented for this. If you don't fix it, every newbie is going to trip up. Every time. Every. Single. Time. It will cost you more time eventually if you don't fix it, not less. Just. Fix. It.
- Not using debuggers. This one was the most hilarious for me. Developers would spend hours adding debug print statements to the code, while I would just create a breakpoint, run the code, and solve the problem immediately.
Lesson learned: programming is 10% typing, 90% debugging. If you use an editor like VI or Emacs to optimise your typing speed, you are optimising the 10%, not the 90%. You've failed fantastically badly at your job. You're not a typist. You're a correctness ensurer. Act like it.
- Testing is optional in the same way that tasting the food you cook is optional. I mean, sure... if you're really good you can make tasty food reliably. If.
Lesson learned: IDE-integrated test frameworks can save more time than they take to set up. At a minimum, test any "clever" code with every corner-case. Null and empty inputs. One input. Multiple inputs. Max/min inputs. Inputs expected to trigger errors. Etc...
- Reams of dead code left in the source. That dead code had changes made to it after it had become dead. Bug fixes. Renames. Cleanup. Consistency changes. On and on, and on. The staff were easily spending 30% of their time editing code that wasn't used.
Lesson learned: dead code is pure, unadulterated overhead at every step. Checkout? Wasted time. Build? More wasted time. Running tests? Time wasted. Refactoring? Extra work. Etc...
[1] At the time I used EDU.oswego.cs.dl.util.concurrent by Doug Lea, which was amazing. Several modern standard libraries are modelled on it, including Java's java.util.concurrent.
If your exhausting yourself at a desk for 8 hours x5 until complete burn out...well...then you go from writing 80% to 0%. How does that help the company? It really doesn't, and your overall average drops real fast (even though your not there).
Others maybe already get this (or live like it anyway) and spend less time typing code. Taking care of yourself so you can continue to contribute 4-5x of others is far more beneficial for the company in the long run.
Think about the "10x" companies - FANNG if you will - they have bicycles for people to go between campusus's, entire gyms, foosball, etc, etc. They seem like insane perks to the outside world, but it's what give balance to the 10x'ers whom work there - and they do it on company time.
Good luck!
So be it. This may be harmful to your team/company in the short term but it will make it clear that there is a gap in output and productivity within the team that must be addressed. Go lift heavy weights (im talking about iron).
If I died, I don't care.
If I left the project entirely, I don't care. I've moved on many times over my career. I can live with that.
But... if you leave early for a bit, then things "fall apart" and you have to then fix things.... that is the bigger concern. It's the 'fix it' part that bothers me.
How often are you actively learning from and engaging with them on exciting new tech (or the systems you've designed and how they can be further improved, etc.), compared to water-cooler talk?
From a point of self-evaluation I think it would help if I tried to listen more than talk.
You're hitting all of the points many people are still striving for.
Perhaps it may be worthwhile seeking a professional's opinion, as the problem may be deeper-rooted than can be explored via forum.
I truly appreciate it.
> Logically, I know that's not true. If I died today, the company or my team would not collapse.
Even before I got to the next sentence I recognized this from my own experience. You’re experiencing acute burnout.
It’s hard to disconnect from that, but I can tell you (again from experience) that you need to find a way to do that.
My advice is to set yourself a goal, to become a .1x developer for a clearly defined amount of time. A month is a great minimum. Go travel or even just find a fishing hole or something that feels relaxing and detached from work and just… don’t be at work.
Either you come back recharged and reassured that your team is as capable as your rational-voice mind is telling you, or you come back to flames and realize you deserve a better role that supports you.
Regardless, you come back with some time away to rest and think about what you want for your life, including whatever is next in your career.
If you are working salaried job and not earning 3x as your peer, yet you worry things will fall apart? Something is not right. Most likely you need to ease a bit on work, see nothing will fall apart or if it does ask for huge raise.
I assume you are referring to some sort of productivity methodology like GTD.
This is inadequate. Adults need "love" and companionship from adults in our lives. The love of children is inadequate; we must also have strong ties with buddies, pals, compatriots, and colleagues for mental health.
Children can never fully deplete adult loneliness.
I think you will feel better. I certainly do, on a similar regime.
On the loneliness front, I meant in the scope of working. I have four kids, I am everything BUT lonely with them.
However, I do agree that aside from work and one of my hobbies I have neglected my health, specifically I need to eat healthier, exercise more and lose some weight. I've debated working one hour less than I'm supposed to just so that I can exercise daily, but I find myself worrying that without me things will fall apart.
Logically, I know that's not true. If I died today, the company or my team would not collapse. Nevertheless I feel that if I'm supposed to be working from 8-5 (which 1 hour lunch), I need to actually be working.