Tell HN: The loneliness of a pretty good developer
It didn't start this way. I became a Jr Dev at 33 years old, people consistently assumed I was more experienced than I was. I'm not sure if it was my life experience or my relentless pursuit of self-improvement but I have been continuously improving my capabilities.
Around the time I turned 38 years old I felt competent. My code started to become defect proof. The drawback was it took me an extra 20% more time to complete. The Product Owner used to say to me, "I know it will take you an extra two days to a week to complete something, but then I never have to worry about it again". So, solid code, but kind of slow in comparison.
I'm now 42 years old, my code continues to have minimal amount of defects, but I complete stories fast, and I'm not working crazy hours, just the standard 8-5. Of course I'm involved in a lot more meetings nowadays, architectural discussions, bleeding edge Proof of Concepts etc, however that has not slowed me down. It has made me faster.
I never set out to become some kind of uber developer, but in the last couple of years I have noticed a shift in behaviors around me. It started with little things. Tech Leads inviting me into meetings to express my perspective on things. Developers pinging me when I have never worked with them, because "you probably know the answer". Being asked to weigh in specific Code Reviews outside my department. Lately if I join a meeting with people I haven't talked to before they already know who I am. Even my manager has started introducing me by just saying "This is X, you've probably heard of him".
Someone run a query to see the number of git commits by user for the application group I am in, about 350 developers. A script I wrote that performs various automation tasks was number 1, I was number 2. This surprised me, and it was an event that brought some of my thoughts and feelings into focus, thus this lengthy post.
I don't think that the number of git commits actually proves anything, other than I commit, code review, and merge code frequently. I wanted a better metric to quantify my feelings of alienation. I looked at Jira stories and story points. In my direct team of 10 people, myself included, I have completed 71% of all story points in 2022, the other 9 are responsible for the other 29%. That jives with my number of git commits compared to others as well.
So what's the point of this thread? It's not to brag, if I came across that way, I apologize. The problem I'm having is it's lonely and stressful.
This feeling of loneliness got quantified when the commit number came up. The problem is people just accept whatever I say. I used to get challenged in some of my decisions, which I always appreciated since I could create better solutions. Nowadays people just accept whatever I say as the best way.
It feels like I don't have peers. I'm solely dragging my entire team and everyone else around me with me for the ride. This leads to stress, it feels that if I am not working on the "thing" it won't get completed.
I worry that by not being challenged I will become complacent.
I catch myself becoming more controlling because at this point about 80% of the code base is my code for the applications my team is responsible for. I don't think that's a good thing, at the same time what I find plainly obvious is not to others.
The worst part is I am sensing within myself this frustration that everyone else appears to move so slowly. The thought of "great, one more thing I got to fix" is coming up too frequently.
To summarize, I'm a pretty good developer. I love writing code. However I feel alone, and I'm afraid I will become conceited of my own abilities. If you can empathize with this I would appreciate your perspective. Am I the only person feeling this way? What can I do to chang...
518 comments
[ 2.9 ms ] story [ 334 ms ] threadFair worry.
> What can I do to change things?
You should switch jobs.
I've been the top technical person at a couple of companies (not the size of your company, however). It can be exhilarating to be "the person". You get a lot of respect and autonomy. But it can be easy to fall into the curse of the expert beginner: https://daedtech.com/how-developers-stop-learning-rise-of-th...
While you can mitigate this to some extent by participating in groups (virtual and physical) for other great developers, the easiest way to handle this issue is to switch jobs.
So, I'd suggest you start interviewing. Either you'll find a better place, or you'll discover advantages of your current situation.
Advice for OP: what companies do you admire? Either globally or locally? Have conversations with folks at that company (LinkedIn is your friend in accomplishing this) and see what people actually working at these companies think about challenges and accomplishments at their employer.
Big fish in small pond still describes the need for room to grow accurately enough.
I've been "the goto guy" at a few places, usually just ended up that way over time, and when I switched jobs, suddenly it felt like I didn't know anything, or at least had a lot of catching up to do.
Like I was a SME at my previous company, that got pulled into a bunch of meetings, and was often brought up and thanked in multiple town hall meetings for various projects I worked on.
At my new job, it was obvious that everyone was using technology and architecture that I was never exposed to and I had a lot to catch up on, and I still am. I am definitely not a SME here. Although I have been on one project just long enough that I will start helping onboard and overseeing some junior engineers soon, it sounds like.
Also, I'm smart and can pick up things quickly, but I would never consider myself a 10x engineer.
FWIW, one of my friend is the maintainer of one of the most popular FOSS. He doesn't code as much anymore, but instead focusing on building relationships with people, like a dev evangelist. He seems really happy doing it.
Currently I train new developers with all the tools we are using, and our CI/CD process. I mentor one new hire in six month cycles, and yesterday I got an intern mentee.
I also write a lot of technical docs mainly as a way to explain to others how different parts of the system function. As I make code changes, I update the docs as my own personal definition of done.
In terms of a college career, I'm not sure a college could pay me as well.
It would probably be cool to explain that to others. I enjoy talking about the developer mindset I possess when mentoring Jr Devs that cycle through with me.
“If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.” -Attributed to Antoine de Saint-Exupéry
I often feel like I’m working more efficiently towards a goal than colleagues (and I work with others who make me feel inefficient, too), but that’s my opportunity as a tech lead. Help them figure out how to unblock themselves and motivate them towards the vision.
Why not move into a domain where you're a beginner again and feel what it's like to struggle to learn from scratch?
In terms of moving to a different domain I did about 4 years ago. It was a challenge in the beginning, but I have enough life experience to know how to handle adverse situations.
Kind of like if you know 3 programming languages well, the 4th one is not very hard. It becomes a "what keyword do I use" to do the thing.
Do a university course or move to a new country and learn a language, start a business. Apply your ability to handle adverse situations and think your way out of this.
If you are lonely then spend your time helping other people to solve their problems their own way rather than yours. Take up gardening and devote your ability to that. One can go on and on.
It becomes hard to find a job you can live with.
I didn't mind being the smartest person around, but I did find it a relief to be surrounded by other people at or greater than my level when I switched to a different team.
I mean, if I would perform so much better than my coworkers, in the end that would lead to me doing all the work for basically the same pay. So it would be an opportunity to find a more challenging gig.
Do you want to be an engineering leader? This is what you are, regardless of your official title at your company. Engineering leaders are judged by how much better they make everyone else. You may hear the term force multiplier used. Say you are really a 10x engineer, how much more effective are you if you could improve the efficiency of 350 developers by 10%? Mentor, teach, help establish culture, make systemic changes to help your peers become more effective.
Regardless, I think you're a bad fit for your current company and its culture. And yes, many of us have worked in environments, like a startup, where we knew we were critical to success. Fail to deliver and a funding round wouldn't go through and people would lose their jobs. It's stressful, but I hope you're adequately compensated.
My problem is that I love code much more than talking to people all day. I have been mentoring Jr Devs for a while now in an official capacity which helps.
I like the idea of "make systemic changes to help your peers become more effective". So that's something I will have to think about.
I know this because I've watched it happen many times, not because I'm one. I've had lead developers report to me and good ones can really have a great impact. The tooling, procedures, technical debt, etc. All will be positively impacted by someone like you.
BTW that's not isolation you're feeling. It's responsibility, respect, and frustration. You didn't ask for the first two, you earned them.
Specialists and Generalists tend not to respect each other, for example. Folks with CS degrees and autodidacts likewise (though both can have impostor syndrome comparing themselves to the other).
There are also three personality types (or cultural types) suited to different maturity stages of the system being worked on (which also implies different processes, BTW): Pioneers, Settlers, and Town Planners[0][1]. Many businesses tend to collect one or two of the three types. Pioneers+Settlers is viable, as is Settlers+Town Planners. Orgs that only have Pioneers+Town Planners tend to have interesting pilot programs that never get successfully rolled out.
[0] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
[1] https://swardley.medium.com/what-culture-is-right-for-you-ba...
I accept you're a gifted coder, and that you're better than your peers. Good, then do exactly that.
Being good at mentoring people is only vaguely correlated with being good at code. IMHO, the main factor that will make you good at something is caring about it, and if you don't want to talk to people you'll waste your skills.
There is someone out there who would love to talk to people, worry about their development, figure out how to best use your skills and so forth. Let them do it.
It seems to me, though, that OP vastly much better at that, than the others available. And that his co-workers have noticed this too.
A few interesting questions that come to mind.
1 - Does OP feel like they are doing the same things over and over again?
2 - Does OP want to work with better/more skilled engineers?
3 - Is OP setting the technical direction? Do they want to?
Being the top coder by commits in a group of 350 is a super power, however many "Hard" software problems are resistant to code throughput as a fix. There are extremely difficult software problems that take years to produce the ~1k line solution.
If you haven't read it, "Staff Engineer" outlines some of the ways more experienced engineers continue to grow and provide value without becoming managers. I'd say the first half of it is worth a read to see if it sparks anything for you.
I will say that it gets lonelier as you go along either track. Reach out to peers if you have any. If not, try to reach out to folks outside of engineering.
It's a tricky path, and I wish you the best.
I suspect they are feeling stressed because they're the main goto person on the product, and with enough random bobble heads running around trying to commit sacrilege on your codebase it quickly becomes a problem of control to maintain the quality you've so strongly instilled vs allowing the product to progress.
Their best path to get out of this bind I'd say is to slowly try to make themselves redundant on that product, choose a victim dev to be your successor and gradually disengage. Possibly a new product or project will be started and then they're free to get involved in that instead.
Also learn how to interview new candidates and get involved at that level, getting good (even better than you) coworkers is a great way to influence the whole company culture and make your work life much more pleasant.
That being said, tech megacorps are stressful environments, and OP looks like he has his plate full just accepting that he's become the de-facto lead developer. OP built his own niche market, why not dial it back a bit from eleven and learn to enjoy it?
I like mentorship, helping people figure stuff out, giving technical advice etc. I don't like going to zoom meetings all day, which is what "leadership" in today's modern world has become.
Hobbies, sports, instruments, hell even a book club. Get social outside of work. Treat it the same as you’ve been treating your career (dig in and get good). You’ll find you make friends outside of work, but often at work too, as you may have hobbies in common with others at your job.
This will naturally lead to a good work balance, because you may end up wanting to clock out early to get back to your hobby. You’re in a great negotiating position to reduce your hours when that happens.
- Code editor plugins (or web or mobile apps) tailored to your org‘s workflows
- Language changes in case your org is using an OSS lang
- Libraries for often-used functionality
- DSLs that let your org‘s PMs encode behavior themselves
- Small utility apps (web or mobile) that facilitate more effective communication
- Dev tools for your stack, eg if you don’t have hot reloading yet, that’s a huge enabler
- Test data generators
- You mentioned that you setup automation. Take it a level further and let other devs create scripts by preparing an environment (maybe an IDE) for that
There are no hard and fast rules, but stuff that increases the productivity of other in a (to them) non-mystical way would be best.
It's a judgement call, some of these in the list above made me pause, but the red flags will be specific to each workplace.
The keys is to know what others will understand, and that is a super-power in itself.
It's always possible to find people who are so much ahead of you that you'll need to put effort into just following the conversation with them. And when you do, they're your peers and you're proud to be a 0.9x developer alongside them.
If you're not enabling your team to take over your job, you're doing it wrong. And by a comment I saw elsewhere, the tendency to control things is natural, but you should resist that - it's the only way you can scale.
If your organization doesn't have that kind of individual contributor leveling, that would be a good conversation to have. Or if your team isn't big enough, maybe its time to look for a new challenge.
There will be a learning curve and a mindset shift, but it's really the only way that you truly become a force multiplier.
Soon, your commits will go down, but your reviews will go up.
Later, your reviews will go down, but your strategy/design/planning docs/conversations will go up. Your job is designing for the 1-3yr future (or more but rare) and across the organization.
Honestly, I have no need for validation. I've just started to feel angst and figured if there is a place where I can get good advice, even if it hurts, it would be HN.
From that perspective I have gotten enough good input to make this thread worth it to me.
I just checked. In 2021, only two defects were created against my specific code changes. If I had to home into a weakness of mine is that sometimes I solve today's problem well, but don't think extensively about how tomorrow's problem in that space might look like.
The struggle is between creating simple solutions vs over-engineering for future proofing. I'm pretty sure I'm biased towards simple solutions.
I want to encourage you to keep learning about your own biases here but to continue to have that bias as much as possible.
I like the term "throw away code" here but I think another way to say it would be that most of the code I write is like a jig for woodworking. I don't need it at the end of the day, it looks like shit, and holds up the real Things while I figure out how those things actually work.
Sometimes in code though, I find, that the jig _is good enough for now_ and it's super easy to replace the three that break instead of all 20 I needed to build it.
- It's impossible to understand what is going on (For example when people load huge json or sql files into a single test and you don't know what scenarios it covers because they are too lazy to write dedicated minimal test cases. Another common offense is a not well-defined data model that gets mutated everywhere in dynamic languages like Python or JavaScript where you never know what shape an object has or where it comes from)
- Their code allows so little extensibility that following the same "pragmatism" as they did and just hacking it in would exponentially increase the complexity
- There are no abstraction boundaries which almost surely means insufficient test coverage (which I have to amend before I can even start with my own work so that I don't introduce regressions) or the tests are coupled so closely to implementation details that any change necessary for my own work will require me to rewrite all the existing tests
You are fast because you pawn off your design work to whoever comes after you. Of course you have fewer defects: your colleagues have to put in more time to maintain the same level of correctness or else risk introducing bugs. That's the cost of bad maintainability. It's well known that changing existing code is harder than writing new code, double so if it is not written with care. Someone has to be the janitor to keep the cruft from accumulating and if it's not you, then everyone else has to pick up your slack. Ideally, every person in the team would continually clean up and always leave a code base better than they found it.
Lastly, I want to say that there is very important difference between simple and easy and simple doesn't come for free.
Now my first 2-4 years, that happened a lot, and I am not going to claim that I was fast. I was slow and either the code review would point something out that I would literary have to start from scratch or the next person that touched it would have to. This was actually the driver for me to focus more on simplicity. I basically discovered a direct correlation between complexity and how bad my code was.
To this day, if I catch myself doing something overtly complex it's a sign that my solution to the current problem is inadequate.
Ironically, my response would be the same if my code was trash. So I won't be able to convince you regardless.
> I'm now 42 years old...
That's 9-10 years.
I'm speculating here but I think that you have some major hurt and pain in your past and something OP said is triggering the memory(ies). There definitely are (many) people in the dev world that do what you're accusing OP of doing, so I'm guessing you've been heavily burned by that (as have I). I actually moved industries to get away from that. In my case it was the Java (especially "enterprise" java) culture/ecosystem/etc, and things got a lot better for me when I wrote off my deep investment in Java and pivoted to C++ and Ruby. I would definitely advise to move around early and often, both company and tech stack. Try out startup life if you've been in big corp, or vice versa. IME startup life is a lot more prone to the "ship it fast" pressure that results in terribly unmaintainable code, so a big corp where you can work on a core product (core enough that it gets plenty of investment and appreciation but not enough that it's the number one money maker, otherwise the Eye of Sauron will be omnipresent and encouraging bad practices). Life is way too short to be miserable at work, especially in a field like ours where hold a ton of the cards.
What you bring up is a common and concerning scenario. It would be better received without the accusatory tone, until you know more about actual situation. There are many good and fast developers that don’t apply to this concern.
It sounds like you might already have a nose for what makes a good dev (i.e. somebody who holds the same values as you) It's a great way to influence the company culture, and get good co-workers, which can also de-stress you as you now have fellow travelers whom you can trust with tasks.
It's also fun, sometimes humbling but always interesting!
This. I'd conjecture that this has led to OP becoming overconfident.
I also think that OP should not be a manager. If one dev is doing 70% of the work then that's either bad hiring practices or micromanagement where other team members are not trusted to deliver complex projects.
Someone with the management sense would’ve already started thinking and implementing that and not continue to code moar.
You don't know they haven't already starting thinking/implementing ways to address those risks. And... it may also be that there's not enough political power to make changes substantive enough to address the systemic risk. OP mentioned 300+ developers on a team - that's a large place. There may simply not be the ability to wield enough influence to make real change to reduce this sort of risk across the board.
Documenting your own stuff, coming up with some better ways to share knowledge, pairing, etc - that can help reduce some localized risk, but you don't know that they've not done this.
But post also points to being lonely of sorts and a sense of dispair. As your last paragraph describes, if OP pair programs, does some mentoring, etc, why would they feel lonely and post on the internet instead of chatting it through with the people at the company?
If so many people are coming to him/her for things, they def have some implicit power. Not knowing how to constructively use that power also lead to my support of the “don’t be a manager” post (yet). If OP figures out how to scale themself out, then by all means…
Nailed it
https://news.ycombinator.com/posts?id=bspear
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- so much so that users are emailing us to complain.
Normally we'd ban such an account as a spammer, but you've posted about plenty of other things and seem like an obviously legit user, so I thought I'd ask instead.
I worked for a famous Japanese imaging corporation for almost 27 years. The pay was meh, the corporate overhead and B. S. was damn near unbearable.
But I worked as a peer with some of the finest engineers and scientists in the world, on a daily basis, and we respected each other (but often also wanted to strangle each other).
I was seldom the smartest person in the room (and I’m smarter than the average bear). It was humbling, challenging, and exciting.
I became a manager, and hated it. I was a very good manager, but spent my nights and weekends, coding.
Since leaving that company, I went straight back to coding, and I’m not as good as I was.
I’m way better.
I don’t really care whether or not I’m better than anyone else, but I find that I can usually meet any challenges thrown my way[0].
It seems that I picked up some good habits, along the way.
These days, most folks in the industry don’t want to have anything to do with me. I’m radioactive. It only took a short time to figure out that no one wants Pops on their team. I won’t go where I’m not wanted.
I’m extremely fortunate, in that I can support myself without earning a salary. I sought out people that want to help others, and have been working with them, for free.
It’s working for me. I’m not lonely at all, and I’m pretty motivated by the work.
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
Try writing code, something wildly out of your specialty. Example: if you are good at crud code, try writing game code.
If you want to level up code wise, then you need to connect with people at meetups or conventions.
You have to keep perspective on life and work.
I know saying this is easier than doing it, but; seek upward movement until you no longer feel like you're the smartest person in the room.
I would also add, although it's purely personal opinion, that seeking a solution to loneliness through work is a surefire way to feel more lonely. You say you're big on self-improvement, but are you only focused on improving your work-related skills? All areas of life need attention, and it sounds like you've only been focusing on the work part of work/life balance (work/life balance is so much more than just what hours you work).
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.
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.
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!
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 think you will feel better. I certainly do, on a similar regime.
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.
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.
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 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....
> 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.
I assume you are referring to some sort of productivity methodology like GTD.
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 believe that if you are already feeling lonely, despite working somewhere for X number of years, the solution is very likely not going to be found at that same place of work.
If you have friends at work and they come to your wedding, congratulations, my thoughts on the situation are not suitable for your situation and you are more than welcome to (and should) ignore it.
Easier said than done. I found smarter people only in few teams in FAANGs, but never in other companies.
Unfortunately there are many other aspects that we need to balance out in life other than being in the right room.
My next line literally says "I know saying this is easier than doing it,"
>Unfortunately there are many other aspects that we need to balance out in life other than being in the right room.
And then I finish with "work/life balance is so much more than just what hours you work"
So... yes. I agree?
What do you mean by "upward"? If it's the classical meaning: you're not guaranteed to find smarter people higher in the organization.
I could have said "seek movement until you no longer feel like you're the smartest person in the room", I guess.
And you realize that person spends their life handing out wisdom which consistently just falls on deaf ears.
It's an empty journey with an unsatisfying end even if you make it to the top.
The money's great, but if you are smart enough to be constantly walking into bigger and better rooms, you should also be smart enough to realize there's diminishing returns on personal wealth but diminishing supply on personal time.
Sometimes the best strategy in winning a game is not to play.
As an aside, you can be smartest in programming and even managing teams but you might still not be most sociable, strongest, most musical, richest, most charismatic, funniest, most attractive, <insert adjective here> person.
If the only measure you go by is IQ, you're childishly defining the game all other kids are supposed to play and then wonder why no one plays with you. That would definitely not be smart.
> I know saying this is easier than doing it, but; seek upward movement until you no longer feel like you're the smartest person in the room.
Since there are many dimensions of intelligence, the above is very underspecified.
Once you disabuse yourself of the fallacy that there is a single dimension of intelligence, it opens up a whole new world of possible mindsets. This allows you to rethink your goals and even your metrics for fulfillment. Perhaps it is more rewarding to think of how you complement others, for example, in terms of capabilities, personality types, and life experience.
Intelligence has many forms, athletically gifted, musical, emotional, the list goes on.
Your classical & narrow definition of intelligence is outdated.
To be a true polymath - as is hinted throughout this entire discussion, there's a need to nurture more than ones intellectual prowess.
I'm slowly coming around to the idea that intelligence doesn't have dimensions or types per se, but something skin to modes that are skill-like, and while there are aptitudes (largely biophysical) that may either preclude or predispose one to enjoy certain activities, what really determines ability in particular modes is how much you invest into practicing that mode (often unconsciously), simply because that's what you find comfortable or pleasant.
You get high EQ if you enjoy figuring people out so you spend more time doing that, but other factors like introversion may affect how often you afford yourself the opportunity to even try. You'll have a low EQ if you find it hard to meet people's gaze directly. In general, high EQ is correlated with empathy (so you enjoy anticipating other's needs). However, psychopaths lack empathy, but if they are highly intelligent (ie. high g) they are often extremely observant master manipulators of others' emotions.
Someone who is tone deaf is unlikely to be particularly interested in music (possible exception: percussion). Manual dexterity (but not necessarily hand-eye coordination) figures in pretty strongly for mastering an instrument. Perfect pitch is definitely a nice-to-have, but some people don't have a voice with a particularly broad range. So who is more "musical" , the popular and theatrical singer-songwriter (that doesn't actually write any of their own songs), or the Pop songwriter that can't sing and gets stage fright? Perhaps the renowned violin or classical guitar player?
Ability in higher (or "pure") mathematics is somewhat associated with musicality (though not the reverse), but neither is particularly correlated with arithmetic (which is what most people mean when they say they aren't good at math). I suspect that what's actually going on is that high g individuals who enjoy constructing deconstructing and recombining particular kinds of abstractions that often can be aesthetically represented as mathematics or as music. Nudge that aptitude in one direction and you get a mathematician. Nudge it a different way and you get a musician.
Athletic giftedness is most dependent on things like physical build[0], genes that code for building extra muscle, other genes that code for more efficient oxygen transport, higher pain tolerance, and so on. Fast reflexes can help, and a lack of any number of contraindicators like poor eyesight or vestibular problems. The closest we have to an innate "athletic intelligence" is proprioception, and I think the jury is out as to whether that's an attribute of the central nervous system or not.
Basically, if you can get into a state of flow such that what you're doing is just challenging enough to keep you engaged and there isn't anything that derails you, you're going to get better at that thing. If you enjoy doing the thing you're going to enjoy getting better at it. Your aptitudes (including fairly abstract ones like right or left brain dominance, or Big Five personality factors), can push you in particular directions at the outset and keep giving you nudges in that direction, as can your environment, but most people start out with a broader array of these than they end up leaning into. We all know people who stopped drawing because of unkind feedback or comparisons with others in their age group, for example. We've also seen a huge explosion of computer-mediated visual art made by people who never really learned how to draw well with pencil and paper and that use a mouse but not a stylus, that in an earlier age would not have been labelled "artisticly inclined".
In short, these so called different intelligences or ways of thinking are more like skills that are encouraged or not by the environment you're situated in (including your body); you get better at them the more you use them a...
How would you respond to the following criticism? Isn't this just semantics?
What are some benefits of shifting the labels of various skills and traits such that they get included under the umbrella of "intelligence"?
Ok, I'll stop my satanic advocacy now... :)
Let's take athletic skill in particular. Can you help me understand why it makes sense to call it a form of intelligence?
I think it is fair to set aside certain physiological traits that provide athletic advantages such as cardiovascular fitness and muscle composition and body structure (since certain sports/activities often tend to favor certain body types).
Once we have set aside those things, what traits remain that that are 'intelligence like'? (How are we defining intelligence?) Off the top of my head I would suggest spatial reasoning, causal reasoning, planning under uncertainty. Of course someone such as yourself would likely include emotional intelligence especially for e.g. team sports. Am I getting the right drift here?
> Having had the extreme privilege of actually working with some really exceptionally smart people I can assure you that intelligence is a general trait without any significant extradimensionality.
This claim is not persuasive. It also may contain various logical and statistical fallacies, depending on your word meanings. If you want to persuade, I suggest that you'll need to give more context.
A. How do you define "exceptionally high intelligence"?
B. Where and in what capacity have you worked with these people?
C. How do you assess this trait?
D. What do you mean by 'crab bucket ideology'?
E. You are aware that there is considerable scientific writing arguing in support of many kinds of intelligence, no?
F. What parts of (E) do you dispute?
G. What do you mean by 'general trait'?
H. What do you mean by 'extradimensionality'?
I. What do you mean when you say your definition of intelligence "is a general trait that does not have any significant extradimensionality"?
J. WRT (I) are you saying that your definition of intelligence is not correlated nor caused by other traits?
K. Do you have a physiological or biological basis for your claim?
L. Please share sources (writing such as studies) that you find persuasive.
M. What are the chances that we are talking past each other? Do you have questions for me?
There's certainly considerable social demand for this to be true, and Howard Gardner is tirelessly promoting it, but the current expert consensus seems to be against it. Both Stuart Ritchie's _Intelligence: All That Matters_ (ch. 2) and Russell Warne's _In The Know_ (ch. 5) consider the multiple intelligences hypothesis false and have further citations.
This is a fair definition I think:
> midwit: A person of middling intellect.
You recognize this is an insult, yes?
If so, why did you call me a midwit? Does it help you in some way? Does it make your comments more persuasive?
Why did you include 'actually'?
Are you suggesting that I have not?
sometimes i get burned out on it. but, ultimately i am still interested in programming and the creativity that comes with creating products.
so, just glad that I can keep being one for at least 10, maybe 20 more years.
If you look around, you will see that a lot of the struggles of younger age developers are from lack of life experience not specific developer skills.
Have Fun!
It's also about adopting the attitude that "I can always learn more". Just by reading HN that's a really good step, because there are smart people here and interesting posts.
I started professionally as a Pascal programmer on an IBM PC/XT, now I architect OLTP systems and either spend my time debating high level architecture, or I'm down in the weeds watching log files of the apps.
There's always somewhere interesting to go on the journey. Especially if you treat it as about creativity and not engineering :)
That’s not to say you’re bad or your code is bad, but it’s definitely worth considering whether the way you’re measuring yourself is a true reflection of your value: have you talked to your co-workers about what it’s like to work with you? What value you provide to them? How you can contribute to their careers, their work? The greatest value you can deliver to a business is rarely code: if you can improve every other developer by 1x, the business will be much better off than you being on an island all by yourself.
My measure of myself always starts with whether or not people enjoy working with me, whether I’m providing value to the people around me: I could write 10x as much code as I do now, but I don’t believe it would have better results for the company overall.
That doesn't square with how people are going out of their way to query OP though, no? If people drag you into meetings tangential to your work, it seems unlikely that they hate working with you...
There’s complex dynamics at play that are a product of the genius developer mythology: someone produces a lot of code, the system becomes an extension of that person, everyone becomes dependent upon that person regardless of whether the person is good or bad, enjoyable to work with or not, because they’re the genius system-whisperer.
Earlier this year I spent some time at a company that has an incomprehensible system that is deeply problematic and painful to work on — so much so, they brought on dozens of developers to try and speed up the rate of delivery (I was one of them) — but the person who built it (and is most productive in it) has been elevated into a position where he now owns the entire technical implementation for the company, and is responsible for designing the solution to the nightmare he created, despite clearly demonstrating he has no business doing so: he’s simultaneously a linchpin and incompetent.
There’s probably some version of the Peter Principle that applies to software engineering: a software engineer’s output will rise to the level where it’s a burden.
Part of the reason why I made this post is I can sense internally that I'm starting to lean on the whole "I know this thing better than you", which actually scares me. If I'm thinking it, I'm probably sub-communicating it.
Both this reply and your original one are solid thoughts.
> someone produces a lot of code, the system becomes an extension of that person, everyone becomes dependent upon that person regardless of whether the person is good or bad, enjoyable to work with or not, because they’re the genius system-whisperer.
I hope this is not true for myself, but your logic is sound. I see the truth in it, I just hope it's not the truth. You gave me something to reflect on.
Whenever I hand code over I ask, does it make sense? Usually they say something like, yep looks easy.
I used to think it was because I was a dumb ass and only wrote simple stuff, but finally realized it's because I spend large effort on making the code read like english. (Good function names, good variable names, code that looks like logical short sentences, etc.)
All this to say, if you make code it's own wiki, you can avoid "I know this thing better than you" quite effectively, and complex code can be made to seem quite simple.
You may already doing that, but thought I'd share in case it's helpful in any way!
This is normal. The thing that affects the team the most in this case is the complexity of the code base.
A lot of comments are blaming speed for a supposed lack of sophistication, excessive duplication or disorganisation of the code.
But sometimes a developer can be fast is due to someone not introducing unnecessary complexity in the codebase.
A fast developer is not necessarily a 10x developer, but it also isn't making a mess.
Most of the cases of unmanageable code were made by developers with a lot of time and planning on their hands.
This has happened to me in I think almost every company I've worked at. The person at the top really has no business being there and has produced a terribly bad system. Often they think very highly of themselves and have 0 self reflection. They'll be called into meetings as a subject matter expert on things they have no clue about.
The speed thing is also a clue often these dev rattled code out at a high pace without self reflecting on the code either.
Code being perfect and bug free is highly unlikely. I've worked with some very talented devs and there code always had something wrong with it. The type of dev that the OP fit into would argue about something being a bug to make it seem like their code is perfect. So rather than a bug all their bug would become new features. A perfect cop out when something they write is less than perfect.
Doing 79% of the story points is a big red flag. You're hogging all the work when you do this and not letting anyone else in the team learn about what it is your building. It's a bad PO / SM that doesn't notice that one person in a team of 10 is doing almost all the work.
FYI this never ended well for the devs I've seen like this in the past. Either through M & A or change or leadership something will happen that knocks them off the top and their ego will take a massive beating once the new top dev comes in and takes over.
This can have the paradoxical effect of people relying on them less in situations where they should, because they think the 10x doesn't know anything, and instead they turn to the braggart 1/10x programmer who claims he knows everything. (Not meaning the OP on this; I just know a guy IRL who is exactly this.)
(It seems to me, though, that OP is both competent and reasonably confident, a good combination.)
Also: (1) It is easy to say "from my experience" without sampling from it representatively. (2) It can be difficult, in general, to gather life experience that is balanced across all four elements of the confusion matrix. (This is a general statement that includes survivorship bias.)
[1]: https://en.wikipedia.org/wiki/Confusion_matrix
Sometimes the "10x engineer" is just the one that's loudest and most persistent. Doesn't mean they're good. Just means no one else can be fucked dealing with them.
;-)
Iterate fast > perfect
Write it down to relieve cognitive load.
Uni-task (focus on one thing at a time)
Prioritize and execute.
Solve problems by:
a. Invert - improve by subtraction
b. Decision trees - compare outcomes, reduce load
There are two types of decisions. Hard choice (A vs B), or multiple factors (A vs B vs C, but you can do A+B etc).
Hard choice model. Is it a hard or easy choice? Does it have low or high impact. Hard to compare, low impact = apple vs oranges, focus on optimization.
Hard to compare, high impact = get impact and mitigate negatives.
Easy comparison, low impact = Go with your gut
Easy comparison, high impact = Be confident
For multi factor decisions use a decision matrix.
Understand systems by looking at the connection circle or iceberg model.
Connection circle is when you take the key elements and put them on a circle as points. If there is a cause and effect relationship you draw an arrow from one element to another. If arrows end up connecting three or more elements together you have located a closed feedback loop.
Iceberg model, top of the iceberg (what's visible) is the event that just happened, underneath that there are patterns/trends, under that structures and connections. The deepest part of the iceberg are the mental models and assumptions made by people. If it's a system I don't understand I will confirm my path down the iceberg by looking at the code, testing the code and talking to SMEs
In terms of actual code reminders I try to make it work, make it right, make it fast.
I also try to do always, then inhibit, then ignore cases that don't apply.
Minimize if statements to have consistent execution.
If a function is called from one place I will inline it. From multiple places I will try to see if I can have it happen in one place so I can inline it (plus it's an optimization thing). For complex calculations if I can't have it happen once I will try to cache it, but cache invalidation can get tricky, so I always opt for do it once.
Finally I try to write pure functions, look at parameters and return one or more computed value.
I also try to do always, then inhibit, then ignore cases that don't apply.
Minimize if statements to have consistent execution.
If a function is called from one place I will inline it. From multiple places I will try to see if I can have it happen in one place so I can inline it (plus it's an optimization thing). For complex calculations if I can't have it happen once I will try to cache it, but cache invalidation can get tricky, so I always opt for do it once.
Finally I try to write pure functions, look at parameters and return one or more computed value.
What programming languages are we talking about here?
Just lost your credibility lol.
Python is alright but... seriously? Java?
If you've got an suitably anonymous email address I can contact you on, I might be able to offer that other room. (Or you might think it's shite, which is fair).
But yeah, my current employer was my other room. Got to experience imposter syndrome again for the first time in a long while.
Anyway, the hardest part of writing code is starting. Why is that? A lot of times it's overwhelm, you see the task, it appears large and you don't know what to start.
My solution is simple, I start writing the steps I need to take. This will be easier with an example. To not get stuck in weird debates let's pretend the ask is that I need to build a house extension for someone.
I will start breaking that down, in bullet points.
* Figure out location of the extension
* Find out dimensions of the extension
* Order wood and nails
* Bring hammer on Monday to start
At this point I might know what kind of wood I need, hell I might even need to buy bricks. But I have a semblance of steps. I can talk to the client and ask specific questions.
As I go through my list I expand it or make it more focused as I go. Out of habit I also tend to mix thoughts and realizations in my bullet points.
Then as I am going through the solution the following days I can see my thoughts expanding and increasing in specificity.
There is another thing this does. If I find it hard to come up with a few bullet points it means the problem is too vague or I don't understand it well enough. Instinctually you will know if it's lack of knowledge or vague problems. If I lack knowledge I read about it or talk to an SME. Vague problems can be solved by talk to the Product Owner, Business Analyst or a client if it makes sense.
Once I grasp the problem, get basic questions answered I go through my bullet list and refine it. That's when I try to design things. After I have a design I try to see if I'm making any assumptions. Personally I prefer to test any assumptions I have.
I rather find out my assumption is false at the design phase than later. Granted sometimes things can get still trip me up, or give me a false positive.
I don't spend a ton of time designing. If I can I will pitch my design to someone I consider smarter than me to see if they find holes. I prefer people that think more breadth first, because I think depth first. Their strengths is my weakness.
Most of the time in the act of my pitch I will find assumptions I have made or I will realize that what I am saying is overly complex so it probably means I didn't design it well. So I iterate.
Designing doesn't take me long most of the time. I have learned that I think better when I code than when I design.
When I start coding I use a dirty version of TDD. Instead of write test, write code to pass test I follow a different pattern
I write small parts of code that satisfy the most likely case and I write the first step of the most likely case.
For example if I was writing a rock paper scissors game, the first part would be to to right the main method framework and print "welcome to rock paper scissors game". Then I run the code to see it's good.
Next step would be to accept input. Test that. Then write the logic for determining what the CPU will throw. Test that. Then how to determine the winner. Test that. Then create the "you win/lose" message. Test that.
Once that's working I'll start to worry about things such as, what happens is they press enter without any input. What if they miss type a word. I might decide that I would be easier to make it multiple choice, where a = rock.
This is a simplified and contrived example. Sometimes I'll write things I consider easy in one go, but if I have doubts or I am starting to touch complex objects or logic I start testing more frequently.
When I test I don't sit, I keep writing code while the test is running. I test excessively but it helps me to see unintended consequences quickly since my code to test cycle is short it's really easy to identify the source of my woes.
I recommend you figure out how to get to that position, which will probably involve training other developers to take over for you.
If you don’t want to get into management, you could join a large company >3000 employees where there will be dozens of people like you.
Any new position is still pretty high risk, to put the OP in not only the same position they are currently at, but possibly worse.
Feeling of being rarely challenged, loneliness, frustration with slowness, and urge to go and fix "it" have been very present for me over the past 2-3 years. It's been pretty harmful to my mental health. But it's also forced me to look at the bigger picture. So while I feel like I've lost a few years of my career, it's not all lost.
Some things I would suggest :
Don't express your frustration. You care, that's a good thing ! But you can't let the frustration overshadow your knowledge and your message. Seen it in some uber-smart people, and it just makes everyone feel bad.
Act as a teacher? I'm not sure if that's something that interests you, but it's something that'll take some of your time, improve the team around you, make you feel less lonely and make you seem more approachable for everyone. I also find it very rewarding.
Change jobs ? New team, new company, new role ?
If you're interested by CS in general, find people outside of work in the industry that you think are "10x" devs as well (god, I hate that term...)? Simply people you respect that have similar interest. I haven't solved the "how" myself, so if you're open to having some off-HN conversations about this, just let me know and we'll figure something out :)
If you go to my profile...and translate it you will find my email address. Ping me :)
(Cool translated profile name, though :P)
Another option is to embrace the role and lean into mentorship at your current company. But it sounds like that is not something you are interested in at this point, so I would start applying to companies.
It seems to be a situation where there are a surfeit of apprentices and a plenitude of journeymen, but a relative dearth of actual masters. I could be wrong, but I'm a journeyman myself -- one who can see mastery glittering on the horizon.
The hard part is when people start treating you like the Smartest Person in the Room (SPITR). Keep hearing that often enough, and you'll start to believe it. You'll lose the growth mindset that had gotten you this far and start thinking that it was your intelligence that made you and not your effort. This will righteously fuck you over when you eventually do foul up, because you won't see it coming even if somebody rubs your nose in the bug you committed because you'll be busy thinking, "I can't have introduced such a bug to the codebase. I'm smart."
I can't tell you how to counter this. I once lost a job after being introduced to a bunch of executives as the SPITR and saying, "If I'm the smartest person in the room, the rest of you are fucked." That's what I get for misreading the room and actually thinking that maybe I was the smartest guy there, smart enough to get away with mocking a bunch of execs capable of spending on Sunday brunch what I pay in monthly rent without a second thought.
It's the same trap that a shitload of kids get shoved into once their teachers figure out that they're reading beyond their grade level and must therefore be GIFTED AND TALENTED. They keep hearing from the adults around them that they're so smart and eventually they start to believe it. How could they not; they're often too young to have figured out that the adults around them are only human and all have pre-paid annual passes on the Dunning-Kruger Express. And when these GIFTED AND TALENTED kids finally fail, it feels like their entire world has come to an end because they've leaned so hard on their "intelligence" that they never learned any other way of dealing with the world around them.
I know this from personal experience. I got labeled as "gifted" in the 1980s because I didn't have the sense to hide my hyperlexia from the adults around me.
Getting back to your concerns: I can't help with the loneliness. I've dealt with the stress by discreetly working less. I can see the other developers' velocity, and rather than outshining them by a substantial margin I pace myself so that my metrics are only slightly better than theirs. Work that takes them a solid eight-hour day only takes me two, so I quietly take the rest of the day for myself.
Rather than rail against the fact that I've become Peter Gibbons and only do eight hours of "real work" per week, I'm learning to take advantage of it.
I have debated this myself. Some other replies said the same thing. It would definitely help me in other parts of my life. How do you handle people messaging you over slack / teams and not responding for hours?
First; you're gonna become an SME on something. SMEs get Pings. If you're in your "not work" time at 3pm, playing Valorant or whatever, and get a ping; that's going to be annoying. That annoyance isn't justified; its not Right; but that is what you'll feel.
The more important thing is really to set and communicate boundaries. The standard boundary is 9 to 5; so set that, 9am you're on and giving it everything, 5pm you're off and giving it nothing (outside of on-call and whathaveyou, which is a separate problem).
It doesn't matter if you can do in two hours what takes others eight; you can't set a 10 to noon boundary. So; you'd have to lie. And its not just a lie to the company; its a lie to yourself. It'll start with "oh yeah im work from home, I'll still keep slack open and respond to pings but this will be me time". Then that me time turns into personal time, which turns into "yeah I can grab drinks at 2pm on a thursday" time, and it legitimately can spiral.
The weird part for me, and I assume some others is: you can't set boundaries in this environment. Maybe its guilt, I don't know. But if you're only on-on for two hours, then kinda-on for... how long? All day? If the 2pm ping induces the same feeling of annoyance as an 8pm ping would, they're not different; and you may become the person to go to if someone needs help at 8pm. Resentment follows: "I'm out with friends, why are they pinging me this late"; but do you not respond? Do you respond "my working hours are 9 to 5 so expect a response then?" Do you believe that when you say it (that's the ironic part; a part of me would).
I can see why you would think this, but I have made it work for me. If I put in enough work in two hours to be slightly ahead of colleagues who need the full eight hour day, I don't regard the other six hours as purely "me time". I regard it as standby/on call time. If a ping comes between 0900 and 1700, I'm there to answer it. That's actually part of the strategy. As long as I'm hitting my deadlines, doing a little better than the other guys, putting cover sheets on my TPS reports, and being responsive during working hours none of my eight different bosses know anything's amiss. They get what they want, and I get more time to exercise, read, play my violin, chat with my wife, tinker, etc.
I don't make anybody wait more than 15 minutes unless the only thing they say in chat is "hello"[0], because they're wasting their time and mine.
I don't mentally clock out at 1100 or 1200 and spend the rest of the day playing video games and resenting every ping. I sure as hell don't start drinking at 2pm. Hell, I don't even keep booze in the house; I only drink if I'm at somebody else's house and they offer me a drink. (I'll have one drink for politeness' sake, but that's it.)
> Maybe its guilt, I don't know. But if you're only on-on for two hours, then kinda-on for... how long? All day?
I feel no guilt whatsoever. I've rationalized the guilt away. If getting paid a salary means I get paid the same whether the work takes 40 hours a week or 80, then it ought to mean I get paid the same whether the work takes 10 hours a week or 40 because I think getting paid a salary rather than an hourly wage should imply that I'm being paid for results, not time spent.
The problem, at least in my situation, is that the company has me on a salary but bills their clients by the hour. This obliges them to track "utilization", so being your kind of honest and outright clocking out when I've finished a reasonable amount of work for the day would foul up my metrics. So I've unilaterally imposed a compromise that works for me: I get my work done in the morning, and spend the rest of the workday "on call" and responsive if something comes up. I make a point of participating in company tech/culture groups so that people see I'm not just focused entirely on client work.
I play the game, but I play it my way because playing it their way is playing to lose.
Remember: boss makes a dollar, you make a dime. That's why you shit on the company's time. I might not be a card-carrying IWW[1] member, but I come from a long line of Wobblies.
[0]: https://www.nohello.com/
[1]: https://www.iww.org/
Happy to knock you down a peg though: You've written code, but what does it do? It's easy to be a big fish in a small pond. If you're that a code you shouldn't even have to be on a team anymore. Why aren't you capturing the value of your work efficiently?
It is lonely because I have no one on my team to go to for different views on most technical or software decisions I make in my everyday work. I like being challenged because that's where a lot of my learning happens.
I'm currently contemplating moving to a larger company (or a more mature software org) where I can have some peers to lean on.