Live data from Hacker News

Tell HN: The loneliness of a pretty good developer

news.ycombinator.com

321–330 of 519 posts

Re: Tell HN: The loneliness of a pretty good developer

#322
It sounds like you enjoy being part of a team where there are plenty of opportunities for personal growth. And being an unchallenged lead developer constantly fixing everybody's problems doesn't provide this, and just furthers the feelings of loneliness. Is this about right? Or am I off?

What would you ultimately like to accomplish with your development? For example, is there a specific problem domain that you would love to help tackle that is maybe beyond your current capabilities?

Who would you love to work with? What might working a different team altogether look like for you?

Ultimately you have all the answers. If I were to provide any advice, it would be seeking out a career coach who can help you bring clarity on where you're at and where you want to be.

Re: Tell HN: The loneliness of a pretty good developer

#323
post #16

I think you're an above average developer working at a below average company. This could be the root of all your problems. Nothing is more frustrating than working with peers you know aren't carrying their weight. 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…

That's what it sounds like to me. Big fish in a little pond. If OP moves to a big pond he'll get a different perspective.

Re: Tell HN: The loneliness of a pretty good developer

#324
post #301

Earlier quoted context omitted.

Re: your second paragraph, what does that have to do with OPs ability (regardless of appropriateness to the firm, his career arch, or the story) to perform as a manager. He/she might be great, normal, or terrible. How can you tell apriori from what they wrote?

OP realizes they do a lot of work, and OP realizes they’re single point of failure/authority at the company. But what steps have OP taken to start decentralizing to mitigate those risks? Someone with the management sense would’ve already started thinking and implementing that and not continue to code moar.

> But what steps have OP taken to start decentralizing to mitigate those risks?

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.

Re: Tell HN: The loneliness of a pretty good developer

#325
How do people get hired at your company? Are you a major part of the process?

Frankly it sounds to me like the situation where you're being taken advantage of by the management, probably because your personality is not aggressive and you don't push in their face how much better you are than most of the other developers.

I'm betting you could earn two or three times what you're making now by moving to a more competitive environment at a company with higher standards. Maybe you don't care about the money, but it could give you the flexibility to retire early and work on whatever you enjoy.

The truth is, people have an odd tendency to value something more if it costs more. By the sound of it you should be making a lot more money than your peers, but I'm betting you're only twenty or 30% above the next developers salary.

Basically, you're undervaluing yourself.

Re: Tell HN: The loneliness of a pretty good developer

#326
post #208

Earlier quoted context omitted.

I've thought about this. I actually do not think I'm the smartest person in the room, hell two of the people in my direct team are definitely smarter than me. I think I have really good systems that allow me to consistently solve problems and write code. 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…

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

Came here to say something similar, as I feel the OP's "fall apart" comment too. However, my bigger anxiety is not that it'll "fall apart", but that things will "fall apart" and then it'll be my role to fix it.

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.

Re: Tell HN: The loneliness of a pretty good developer

#327
post #21

“If you’re the smartest person in the room, you’re in the wrong room.” 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 focus…

I've thought about this. I actually do not think I'm the smartest person in the room, hell two of the people in my direct team are definitely smarter than me. I think I have really good systems that allow me to consistently solve problems and write code. 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…

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

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.

Re: Tell HN: The loneliness of a pretty good developer

#328

Earlier quoted context omitted.

I can go really deep talking about this, so I will just write my personal system pointers that I keep by my desk. 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 factor…

Can you talk more about your method for solving problems? That's normally where I get stuck.

People get stuck solving problems for various reasons. For me, I think more clearly when I write. The primary benefit is that it stops having to mentally re-establish my logical premises to make sure my conclusions are sound.

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.

Post reply on HN