Ask HN: Do you always FULLY understand the code you are working with? | Hacker News Reader

Ask HN: Do you always FULLY understand the code you are working with?

8 pointsDrinkWater9 comments

I wonder if other devs have the same problem as me: i am extremely uncomfortable doing work on code i dont FULLY understand and grasp. Mostly this is due to lack of time, something needs to be fixed urgently, something needs to be extended, etc. I can still get my work done, but as i said, i feel not very good about it (simply put: i hate it).

Is this just me or are other devs experiencing the same?

View on HN

Wait till you go back to your own code in 1,2,5 years and think who wrote this rubbish - only to look it up and find out it was you :-)

This is so true you cannot believe how hard I laughed.

I have a particular coding style (own-prettifying), and so I can tell if I authored the code or if someone else has. I can also tell if mine's been edited by someone else too.

Hahhha... some days ago I checked one of my old PHP codes (I was not aware it was written by me) - I was swearing much.. then I saw my name in a comment on the top and then.. I sweared more :-)

My style is transforming from year to year to a better one (I hope), so sometimes I cannot recognize my old ones.

No one does, that's why we write unit tests. You'll eventually not remember you own code, and you can basically ensure the next guy to come along won't fully understand your code either. If you have good coverage, its like having a safety net to fall on allowing you to take large leaps.

You're not alone. But you're also missing an important point. You often use libraries without fully understanding their code, don't you?

You have to. You usually don't have the time or luxury to dig in and understand everything when you have a specific task to complete. Unless you're refactoring some old code where you try and make sure that you understand everything relevant to that codebase. Or you can just wait until it breaks...

Things like automated testing and proper documentation try to help in this regard, but they're useless if they're not kept up-to-date with the code and they have their own set of problems.

Recently got hired at a new place and I defiantly am having the same problem. There are two major hurdles: Domain knowledge and code-complexity. Then trying to dive into the countless layers of logic in the code itself.

With a large codebase, it's impossible to understand everything. So the only thing we can do is to gradually learn how it works.

Sticking with it will make you valuable to the company in time. Moving on will free your mind to do other things.

Same here. A thing that helped me a lot was to try to divide code parts into boxes, and understand one piece after the other. Even after a year and a half, there are plenty of pieces I can't get. But it gets easier once you can find the main articulations.

I have found that you need to learn to trust other developers work. Even if you are going into their code to fix a bug.. you have to trust the rest of it works!

I think the important thing is not to understand all the code, but to know where you are and why you are there.

Reply on news.ycombinator.com