Live data from Hacker News

Ask HN: Feeling grossly incompetent working in opensource. What do I do?

news.ycombinator.com

11–20 of 27 posts

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#11
post #8

You are doing everything right. Assuming you enjoy the project or product you are working on, just keep at it. You are lucky enough to be experiencing what it’s like to be part of a real software project. It is not at all unusual to be in this position for weeks or even months depending on the complexity of the code base. If you somehow manage to continue until graduation, you will have invaluable experience that vir…

I had a job working on a piece of software that contains bits and pieces written in the 1980s. When I complained about how horribly unproductive I felt, the senior dev on the team just said, "it will take a few years to become productive." It took me a long time to internalize that and appreciate what it meant.

I think it's like becoming an architect spending your career building houses. Houses are small enough that you can reasonably expect to understand every detail of one. And when all you work on is houses, you begin to expect that you'll soon understand the totality of each product you work on.

But then you get a job working on skyscrapers. It's impossible for any single person to understand the entire structure, and you don't appreciate that fact because the concept is still foreign to you. I think a lot of companies have "skyscraper" code bases, and it's not always obvious when you're looking at one. A good hint is probably, any software that's been around for decades and enjoys widespread use is likely to be a skyscraper.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#13
post #8

You are doing everything right. Assuming you enjoy the project or product you are working on, just keep at it. You are lucky enough to be experiencing what it’s like to be part of a real software project. It is not at all unusual to be in this position for weeks or even months depending on the complexity of the code base. If you somehow manage to continue until graduation, you will have invaluable experience that vir…

I had a job working on a piece of software that contains bits and pieces written in the 1980s. When I complained about how horribly unproductive I felt, the senior dev on the team just said, "it will take a few years to become productive." It took me a long time to internalize that and appreciate what it meant. I think it's like becoming an architect spending your career building houses. Houses are small enough that…

qwerty

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#14
post #5
post #2

> multiple layers of abstraction that exists has made it impossible to change even one line of code without it effecting the entire codebase Either you have misunderstood the meaning of "abstraction", or the code base has what people call "leaky" abstractions. The point of abstraction is to create stable internal APIs, irrespective of implementation details. The entire point of abstraction is to create the separation…

> The entire point of abstraction is to create the separation that your code base seems to be lacking. I think this appears to be the problem. The codebase appears to be very kludgey. > This approach is necessary, but you won't really understand the code until you start debugging. Can you tell us more about the stack (and, ideally, the project itself) so that we can give you better tips? Sometimes understanding code…

If you know that you don't know something, then you're already one step ahead of the game, because many programmers dive in thinking that they do understand something and don't find out until it's too late that they never did.

Deciphering large codebases takes a LONG time. Months often, to get up to speed. One thing that has always helped me is to take notes. Especially if you start getting lost in a deep set of function calls. Write all that down. Form hypotheses on what parts of the code are doing and try to come up with ways to test those hypotheses.

Soon it will start to become less murky. It just takes a lot of time and perseverence, even for veterans.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#16
post #5
post #2

> multiple layers of abstraction that exists has made it impossible to change even one line of code without it effecting the entire codebase Either you have misunderstood the meaning of "abstraction", or the code base has what people call "leaky" abstractions. The point of abstraction is to create stable internal APIs, irrespective of implementation details. The entire point of abstraction is to create the separation…

> The entire point of abstraction is to create the separation that your code base seems to be lacking. I think this appears to be the problem. The codebase appears to be very kludgey. > This approach is necessary, but you won't really understand the code until you start debugging. Can you tell us more about the stack (and, ideally, the project itself) so that we can give you better tips? Sometimes understanding code…

> For everyone else in the field it seems like this is effortless

It gets easier the more you experience. I’ve been in the game for around 20 years. I still get caught on sharp edges in code bases. Things still take longer than I originally estimate. Recently, I lost hours on a dumb docker thing because I don’t understand it as much as I would like. One of the code bases I work in from time to time still takes me sometimes days to figure out something that “should be easy,” and I’ve been in that code off and on for literally years. I think you are doing just fine. There are people in this industry who can’t code themselves out of a wet paper bag. You sound like you are already beyond what some professional programmers can do.

Seek help from other contributors to the project. It could just be a shitshow of code that takes hand holding to understand.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#17
Pain is weakness leaving the body, Feeling stupid is ignorance leaving the mind.

Embrace it. School is designed to give you set pieces that can be understood in isolation, the outside world rairly has that luxury. You won't truly improve without discomfort, though the particulars will be personal and multidimensional.

The end skill is solving problems in the wider world.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#18
The best way to tell whether its more about you or the project is to try several comparable ones, some of the biggest and oldest open source projects are practically impenetrable to outside contributors without years or decades of familiarity, this is a problem since the future of such projects is either to be abandoned as their core retires or become entirely dominated by corporations who sponsor the time for people to get on board.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#19
Other people have already given a lot of great advice, so I'll just add this bit:

Working on someone else's codebase—especially if it's an open source project with many different contributors over a long period of time—is its own distinct thing that has to be learned. Everyone has to learn how to do it, regardless of where their abilities as a programmer are. If you are adept (as it sounds like you are) at building your own software, then it can feel like the rug has been pulled out from under you ("Am I actually any good at this?") when you try to contribute and simply can't grok what's going on, but if you persist, you will pick it up. Don't take your struggles now as a reflection of your abilities.

Re: Ask HN: Feeling grossly incompetent working in opensource. What do I do?

#20
post #5
post #2

> multiple layers of abstraction that exists has made it impossible to change even one line of code without it effecting the entire codebase Either you have misunderstood the meaning of "abstraction", or the code base has what people call "leaky" abstractions. The point of abstraction is to create stable internal APIs, irrespective of implementation details. The entire point of abstraction is to create the separation…

> The entire point of abstraction is to create the separation that your code base seems to be lacking. I think this appears to be the problem. The codebase appears to be very kludgey. > This approach is necessary, but you won't really understand the code until you start debugging. Can you tell us more about the stack (and, ideally, the project itself) so that we can give you better tips? Sometimes understanding code…

Usually understanding a new, large code base comes in at least three phases.

1. At first, they always look like overcomplicated incomprehensible crap. Every little thing that you would have done in way X but was done in way Y initially looks like that.

2. But much later on, after you struggled a lot with making changes to the code base, things start to click. You understand why things were made as they were, what the constraints and requirements were. When you want to make changes, you know where they are supposed to go.

3. Then after much more time, it will look like overcomplicated crap again as you understand that people should have said "no" to the more bizarre of the requests, and that much easier solutions for some of the other things exist.

The original programmers started out somewhere between two and three, and as long as they stay involved, they can always guide people, tell them where their changes go or whether they are ill advised. They know which parts are essential to the architecture and which were never meant as more than temporary crap.

You get problems when none of the original programmers are still involved, and you only get people who have to climb the ladder by themselves. Or only have some people in step 1 left. Then the project is dead.

Post reply on HN