30 ms·
> 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 app
by bluedays 7y ago
> 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 is a lot easier with the right tools (IDE, debugger, etc.)
I think the architecture is essentially one of the reasons I am having so many problems. I'm not familiar with docker/apache solr/their custom database, etc. However, I think that's more of a tangential issue. It's more of a feeling of imposter syndrome as another poster said. For everyone else in the field it seems like this is effortless.
> I'm sure you can do it, but it's also important to figure out if you want to. If you work on multiple code bases, including your own, and you don't enjoy it, or the frustration you're feeling now is not healthy for you, then this might not be the right career for you.
It's not really frustration. So much more as feeling like I will never be good enough at this to be successful in this career.
> A lot of being a programmer is banging your head against a wall for many hours longer than a typical person would be willing to, until you finally get past an obstacle.
This is exactly my personality type, and my wife makes fun of me for you. Once I get my teeth into something I basically don't stop until I got it. It's actually created problems for me in other career fields, but it's seen as an asset for programmers. So I know on a personality level I have what it takes, but yeah... Just get the impression I'm not smart enough for this.
- Jeema101 7y agoIf 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.
- sethammons 7y ago> 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.
- Scarblac 7y agoUsually 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.
- AnimalMuppet 7y agoAs others have said, a complex code base can remain opaque for a lot more than three weeks (especially if the documentation is less than flawless). Also, you said that you have two more years of college yet to go. You are placing a completely unrealistic expectation on yourself. You are very unlikely to be able to, after your sophomore year of college, jump into a big code base and understand it in three weeks, even if you're better than others in your class. As for impostor syndrome, I'm stealing this from someone, but how about Meta Imposter Syndrome: "All those other people have imposter syndrome, and yet I see how much they're able to do. So they're not like me, the real imposter." But, in your situation, all those people who are able to get things done in that code base are not like you. I don't know what the code base is, but I strongly suspect that they are out of school, have several years working professionally, and have several years in that code base. Your problem isn't that you're not smart enough. Your problem is that your expectations for yourself are very unrealistic.