Iyfjky

Question

I am a budding programmer and very forgetful by nature.

Having written a decent working app or some code and after about one week if I see the same code, it appears all new to me. It takes quite a lot of time to understand why I wrote that certain logic.

My manager calls me for a discussion to include a new feature in that app and how it would affect the existing functionality. My mind's blank trying to recall and feel so embarrassed.

I do like coding though.

Any of you people experience the same thing: How do you overcome?

As has already been mentioned, make sure you thoroughly comment on and document your code. I would also recommend using software like OneNote or a well organised physical notebook to note down important information as you work on things. — Feb 13 '15 at 8:04
VTC ~ belongs on programmers stack exchange. This is not a workplace issue. — Feb 13 '15 at 11:17
@JoeStrazzere: Forgetfulness doesn't require medical issues. Many things regarding memory require training and practice, more for some than for others. I can remember long strings of random numbers that I overhear in other conversations of which I'm not participating (for a very long time), but I frequently have difficulty keeping dates, scheduled meetings and the like straight without some form of outside assistance (notebook, alarm on my phone, etc). — Feb 13 '15 at 15:25
This widespread phenomenon has given rise to the term "write-only code". It's normally much much easier to write code than it is to read it. Putting comments in is just one aspect of code readability/maintainability. — Feb 13 '15 at 17:47

score 11 · Accepted Answer · 2015-02-13 15:34:22Z

Having written a decent working app or some code and after about one week if I see the same code, it appears all new to me. It takes quite a lot of time to understand why I wrote that certain logic.

That doesnÃ¢Â€Â™t sound like a deal-breaker to me, it sounds like an argument for good comments.

Almost everybody forgets what code they wrote, in the long run. For example, I could tell you the what and why of the code I wrote yesterday, but not of the code I wrote a month ago. Very few people have a perfect memory. So I litter my code with comments to explain exactly why I wrote something the way I did, and I can see my original thought process when I revisit it.

You need to explain the motivation behind the code in your comments. For example, don't write days += 1 // increments days by 1, but days += 1 // add 1 to account for leap years. The former is something anybody can read; the latter is easy to forget, but also easy to record.

More generally, suppose somebody else is reading your code. ItÃ¢Â€Â™s literally impossible for them to remember what you were thinking when you wrote it, so they have to rely on your comments to see why you wrote it this way. Writing good comments is an essential part of writing good and maintainable code.

If you learn to write good comments, then being unable to forget why you wrote something will become much less of a problem.

For a high-level overview, I have a notebook on my desk where I write down what IÃ¢Â€Â™ve been doing. A page a day, with some very brief notes on what I was doing that day (e.g. Ã¢Â€Âœfix the bug-of-doom in function XÃ¢Â€Â, Ã¢Â€Âœdebug test script YÃ¢Â€Â). I can easily flick through it to get an idea of what I was doing recently, and if I need to look at my code changes from a week ago, I can use it to get a very quick idea of my rough plan or aims.

My manager calls me for a discussion to include a new feature in that app and how it would affect the existing functionality. My mind's blank trying to recall and feel so embarrassed.

Sketch out some notes or ideas before you go into the meeting. YouÃ¢Â€Â™ll be much more relaxed, the ideas will flow more freely before youÃ¢Â€Â™re under pressure, and the initial trepidation about the subject will be broken. You donÃ¢Â€Â™t necessarily need a complete design, but just a few notes will make you feel a lot better in the meeting, because you donÃ¢Â€Â™t have to just sit and look a like a lemon while you think.

I was expecting, ppl would suggest a pill or something.. :-))....but On a serious note..Thank you alex — Feb 13 '15 at 8:47
-1 - Comments that say what code is doing are to be strongly avoided. — Feb 13 '15 at 15:14
@Telastyn I thought I was already suggesting "why" comments over "how", but I've tried to clarify my answer. — Feb 13 '15 at 15:35
Good, except that instead of a paper notebook, use something electronic and searchable. I have my work journal in notepad files, and it allows me to quickly search for something that I did months or years ago, providing I can remember an appropriate keyword. — Feb 13 '15 at 16:57
@thursdaysgeek I have to write a weekly report for my manager, so I use that instead of my notebook as the long-term reference, but I agree with the general sentiment of having an electronic copy. — Feb 13 '15 at 17:53

Telastyn 33.9k977120 · Answer 2 · 2015-02-13 15:16:00Z

If you want to succeed, you need to fix the forgetful part. You need to practice information and review it and commit it to memory. There are plenty of sources on how to memorize material. What you are doing right now is throwing information away and it is very inefficient to do that and have to continually relearn the same stuff. So stop doing it. "I am forgetful" is an excuse - it is very possible to learn not to be forgetful.

Start by taking notes, by hand not on a computer. (there is research that shows that handwriting is far mere effective for learning information than taking computer notes.) Take notes about the why of what you are doing not just the how. Then put those notes into the comments. Repetition is a key to learning.

Review your notes before a meeting on a particular subject to refresh your memory on it. Since you have trouble remembering, then review the notes daily. Repetition is a key to learning.

You are expected to know the basics of your profession without having to look things up. I know 90+% of the syntax I use on a daily basis without having to look it up. You should be gunning to reach that level.

Make connections between things. If you treat each new project as something new and strange, then you will have a harder time remembering details. When you start a new project take 5-10 minutes to review in your mind other projects you have done and look for similarities. If you find one, grab the code for that as a starting place.

I find it odd that in one answer, the person can't remember the code they wrote a month ago. I can tell you the specific details of projects I did 15-20 years ago. Not the exact code, no, but the how and the why and the purpose and how that project (written at a different company for a different business domain for a different database backend) is useful in the projects I do today. If you are throwing away your knowledge, you can't get any depth of knowledge which is important to solving the hard problems. Every single really top person I have ever met in any field retains knowledge. It is a key ingredient of the secret sauce that gets you to the top. If you want to work at entry level forever, then keep on using the excuse of I have trouble remembering.

While I agree with the gist of this answer, I find that it's not uncommon to forget at least some of the things that happened last month. Hell, I forget what I coded last week - often because they were small, mostly trivial, and I can spend 30 seconds reading my code to see what I did. — Feb 13 '15 at 15:18
@Telastyn i have the same issues as you - well, actually, i probably have the same issues as the OP. But regardless, HLGEM is just right on the money here. Wouldn't it be better if you could recall the specific details of the code you wrote last week? Wouldn't that make you a better - well, anything? And if so, shouldn't we push for that? After all, isn't that why a company pays more for "experience"? — Feb 13 '15 at 15:26
@bharal - maybe, what's the cost? I mean that time I'm spending on improving my memory of code details could be spent doing other things. I would argue that a company pays more for experience because experienced programmers write clean code that need not be memorized since it can just as easily be read. — Feb 13 '15 at 15:37
I did not say to remember the exact code you used but to remember the methodologies and the why of what you did. And yes, you don't need to retain trivial things once you get experienced enough to undertand what is trivial and once you have improved your memory in general. But for someone who has poor memory skills, it is often easier to start with the less complex things. But basically he needs to learn to stop throwing away information as unimportant. It wil come up again and he will need to know it. — Feb 13 '15 at 15:59
@Telastyn well, arguably this memory-improvement should be done in your own time (at the expense of, say, television or browsing). Also, companies tend to want stuff done that is profitable, not clean code. Developers will argue all day about clean code, but clean code doesn't drive profits. X-treme case:you are hiring a dev to build an app; two choices. Sam is a great dev with experience. Ash is a less great dev, but has literally memorised the entire codebase of a competitor's app, and can write it out in a week. Who would you hire? — Feb 13 '15 at 16:14

score 3 · Answer 3 · 2015-02-13 15:54:30Z

I am a budding programmer and very forgetful by nature.

As others have mentioned, it is good to acknowledge your weaknesses but somewhat counter-productive to ascribe them to your intrinsic nature.

Any of you people experience the same thing: How do you overcome?

Every programmer forgets what they did eventually, especially as they get older.

That said, it sounds as though your code looks foreign to you very quickly. That is not good. In my experience, this happens because the programmer didn't understand what they were doing in the first place. They probably just hacked some stuff together, maybe pasting the code in from other places. They didn't understand what was going on, but could follow the existing pattern enough to make something work. Kinda.

If that doesn't apply to you, awesome. Let's move on to mitigating simple forgetting.

The best way I've found to deal with the fact that you will forget the code you wrote is to be consistent. If your code is consistent, then your old code will look and be shaped somewhat like your new code that you do remember. You can more easily extrapolate what you would've done when faced with a problem, even if you can't remember what you actually did. More often than not, that's enough to work off of.

And it's okay to say that you need to take a quick look at the code to provide your manager with a good answer about how the new feature will impact things.

I really like your point about it being harder to remember what you did when you didn't really understand what you did or why it worked but adjusted some code from the internet. — Feb 13 '15 at 16:20

RualStorge 9,5372231 · Answer 4 · 2015-02-13 16:11:25Z

A slight twist on "Write proper comments"

Good commenting is ALWAYS a plus. By all means anytime you do something unique, hackish, or otherwise not obvious it needs a comment. (Because anything odd probably needs an explanation or you'll wind up revisiting it for no reason other than "what the heck is this nonsense?")

Another thing that goes along way is SOLID design principal and writing "self commenting code"

SOLID design

The entire point of SOLID design is to break your code into it's smallest components to make each and every piece do one thing for testability and reusability.

This also has the benefit of making every piece of code REALLY simple where most of the time the method and variable names alone cover your needs for commenting. (there will always be places that could use additional comments, but the idea is to get it so the code itself is clean enough that you only need the occasional additional comments rather than needing them for every single method)

Self commenting code

Self commenting code is the idea of naming your methods, classes, and variable as such there is no question what's happening at a glance.

If you method is called "FinanceProcessor" you're going to need a comment... Okay... Finance is a VERY broad subject... perhaps a poorly named object? And what the heck am I processing?

Now if that same method is named "UpdateRemainingBalanceByUserId" okay, so that makes sense! I'm going to update the remaining balance based on whatever user Id I provide. I don't know the knitty gritty on how this works, but I now know what it does!

Now lets look at variables... bool payments, bool refunds, bool round, int UserId... Hmmm not very useful... I mean UserId is self explanatory thanks to the method name but am I including these bools, excluding, or something else?

Now if we made these variables... bool includePayments, bool includeRefunds, bool roundToNearestDollar, int OwnerId. Ahhhhh!!! that makes sense! Once again I don't really know how this thing gets it's data for crunching numbers, but I know what it's supposed to do and what these variable will do.

Summary
Adding comments is good, but making clean self commenting code (with comments where appropriate) is better! Cleaner code requires less explaining.

The goal is anytime you look at something in your code you should know WHAT it does without any further investigation, comments should only be necessary for telling HOW it works and little oddities that don't make sense at a glance.

Rajarshi Goswami 1394 · Answer 5 · 2015-02-13 07:13:09Z

up vote
1
down vote

That is why writing proper comments is very important . Heard somewhere " write code as if the next maintainer is a vicious psychopath who knows where you live" . Writing proper comments is a first step before starting code also, as it will enable you and whoever maintains the code to understand without going through the entire code

answered Feb 13 '15 at 7:13

Rajarshi Goswami

1394

Although comments and documentation are helpful, they only help with the first part - in the second part OP is in a meeting with his manager who is discussing features he implemented a week ago. He has no access to code, comments or docs.
â€“Â Konerak
Feb 13 '15 at 7:48

1

The manager asks him something and he will go in without any preparation? That's plain wrong. If the comments is good, he can just a glance at the comments with the manager or himself before going to the meeting to summarize everything or during the meeting also.
â€“Â Rajarshi Goswami
Feb 13 '15 at 7:57

Yes! You should add that to your answer - preparing for your meetings better, documenting what you did, how you did it and why you did it and making sure you can tell anyone anytime. This is not just true for programmers, but for most careers: always be ready to answer the question "what have you done for the company since you joined here?".
â€“Â Konerak
Feb 13 '15 at 8:07

-1 - Comments that say what code is doing are to be strongly avoided.
â€“Â Telastyn
Feb 13 '15 at 15:15

suggest improvementsÂ |Â

score 11 · Accepted Answer · 2015-02-13 15:34:22Z

Having written a decent working app or some code and after about one week if I see the same code, it appears all new to me. It takes quite a lot of time to understand why I wrote that certain logic.

That doesnÃ¢Â€Â™t sound like a deal-breaker to me, it sounds like an argument for good comments.

Almost everybody forgets what code they wrote, in the long run. For example, I could tell you the what and why of the code I wrote yesterday, but not of the code I wrote a month ago. Very few people have a perfect memory. So I litter my code with comments to explain exactly why I wrote something the way I did, and I can see my original thought process when I revisit it.

You need to explain the motivation behind the code in your comments. For example, don't write days += 1 // increments days by 1, but days += 1 // add 1 to account for leap years. The former is something anybody can read; the latter is easy to forget, but also easy to record.

More generally, suppose somebody else is reading your code. ItÃ¢Â€Â™s literally impossible for them to remember what you were thinking when you wrote it, so they have to rely on your comments to see why you wrote it this way. Writing good comments is an essential part of writing good and maintainable code.

If you learn to write good comments, then being unable to forget why you wrote something will become much less of a problem.

For a high-level overview, I have a notebook on my desk where I write down what IÃ¢Â€Â™ve been doing. A page a day, with some very brief notes on what I was doing that day (e.g. Ã¢Â€Âœfix the bug-of-doom in function XÃ¢Â€Â, Ã¢Â€Âœdebug test script YÃ¢Â€Â). I can easily flick through it to get an idea of what I was doing recently, and if I need to look at my code changes from a week ago, I can use it to get a very quick idea of my rough plan or aims.

My manager calls me for a discussion to include a new feature in that app and how it would affect the existing functionality. My mind's blank trying to recall and feel so embarrassed.

Sketch out some notes or ideas before you go into the meeting. YouÃ¢Â€Â™ll be much more relaxed, the ideas will flow more freely before youÃ¢Â€Â™re under pressure, and the initial trepidation about the subject will be broken. You donÃ¢Â€Â™t necessarily need a complete design, but just a few notes will make you feel a lot better in the meeting, because you donÃ¢Â€Â™t have to just sit and look a like a lemon while you think.

I was expecting, ppl would suggest a pill or something.. :-))....but On a serious note..Thank you alex — Feb 13 '15 at 8:47
-1 - Comments that say what code is doing are to be strongly avoided. — Feb 13 '15 at 15:14
@Telastyn I thought I was already suggesting "why" comments over "how", but I've tried to clarify my answer. — Feb 13 '15 at 15:35
Good, except that instead of a paper notebook, use something electronic and searchable. I have my work journal in notepad files, and it allows me to quickly search for something that I did months or years ago, providing I can remember an appropriate keyword. — Feb 13 '15 at 16:57
@thursdaysgeek I have to write a weekly report for my manager, so I use that instead of my notebook as the long-term reference, but I agree with the general sentiment of having an electronic copy. — Feb 13 '15 at 17:53

Telastyn 33.9k977120 · Answer 7 · 2015-02-13 15:16:00Z

If you want to succeed, you need to fix the forgetful part. You need to practice information and review it and commit it to memory. There are plenty of sources on how to memorize material. What you are doing right now is throwing information away and it is very inefficient to do that and have to continually relearn the same stuff. So stop doing it. "I am forgetful" is an excuse - it is very possible to learn not to be forgetful.

Start by taking notes, by hand not on a computer. (there is research that shows that handwriting is far mere effective for learning information than taking computer notes.) Take notes about the why of what you are doing not just the how. Then put those notes into the comments. Repetition is a key to learning.

Review your notes before a meeting on a particular subject to refresh your memory on it. Since you have trouble remembering, then review the notes daily. Repetition is a key to learning.

You are expected to know the basics of your profession without having to look things up. I know 90+% of the syntax I use on a daily basis without having to look it up. You should be gunning to reach that level.

Make connections between things. If you treat each new project as something new and strange, then you will have a harder time remembering details. When you start a new project take 5-10 minutes to review in your mind other projects you have done and look for similarities. If you find one, grab the code for that as a starting place.

I find it odd that in one answer, the person can't remember the code they wrote a month ago. I can tell you the specific details of projects I did 15-20 years ago. Not the exact code, no, but the how and the why and the purpose and how that project (written at a different company for a different business domain for a different database backend) is useful in the projects I do today. If you are throwing away your knowledge, you can't get any depth of knowledge which is important to solving the hard problems. Every single really top person I have ever met in any field retains knowledge. It is a key ingredient of the secret sauce that gets you to the top. If you want to work at entry level forever, then keep on using the excuse of I have trouble remembering.

While I agree with the gist of this answer, I find that it's not uncommon to forget at least some of the things that happened last month. Hell, I forget what I coded last week - often because they were small, mostly trivial, and I can spend 30 seconds reading my code to see what I did. — Feb 13 '15 at 15:18
@Telastyn i have the same issues as you - well, actually, i probably have the same issues as the OP. But regardless, HLGEM is just right on the money here. Wouldn't it be better if you could recall the specific details of the code you wrote last week? Wouldn't that make you a better - well, anything? And if so, shouldn't we push for that? After all, isn't that why a company pays more for "experience"? — Feb 13 '15 at 15:26
@bharal - maybe, what's the cost? I mean that time I'm spending on improving my memory of code details could be spent doing other things. I would argue that a company pays more for experience because experienced programmers write clean code that need not be memorized since it can just as easily be read. — Feb 13 '15 at 15:37
I did not say to remember the exact code you used but to remember the methodologies and the why of what you did. And yes, you don't need to retain trivial things once you get experienced enough to undertand what is trivial and once you have improved your memory in general. But for someone who has poor memory skills, it is often easier to start with the less complex things. But basically he needs to learn to stop throwing away information as unimportant. It wil come up again and he will need to know it. — Feb 13 '15 at 15:59
@Telastyn well, arguably this memory-improvement should be done in your own time (at the expense of, say, television or browsing). Also, companies tend to want stuff done that is profitable, not clean code. Developers will argue all day about clean code, but clean code doesn't drive profits. X-treme case:you are hiring a dev to build an app; two choices. Sam is a great dev with experience. Ash is a less great dev, but has literally memorised the entire codebase of a competitor's app, and can write it out in a week. Who would you hire? — Feb 13 '15 at 16:14

score 3 · Answer 8 · 2015-02-13 15:54:30Z

I am a budding programmer and very forgetful by nature.

As others have mentioned, it is good to acknowledge your weaknesses but somewhat counter-productive to ascribe them to your intrinsic nature.

Any of you people experience the same thing: How do you overcome?

Every programmer forgets what they did eventually, especially as they get older.

That said, it sounds as though your code looks foreign to you very quickly. That is not good. In my experience, this happens because the programmer didn't understand what they were doing in the first place. They probably just hacked some stuff together, maybe pasting the code in from other places. They didn't understand what was going on, but could follow the existing pattern enough to make something work. Kinda.

If that doesn't apply to you, awesome. Let's move on to mitigating simple forgetting.

The best way I've found to deal with the fact that you will forget the code you wrote is to be consistent. If your code is consistent, then your old code will look and be shaped somewhat like your new code that you do remember. You can more easily extrapolate what you would've done when faced with a problem, even if you can't remember what you actually did. More often than not, that's enough to work off of.

And it's okay to say that you need to take a quick look at the code to provide your manager with a good answer about how the new feature will impact things.

I really like your point about it being harder to remember what you did when you didn't really understand what you did or why it worked but adjusted some code from the internet. — Feb 13 '15 at 16:20

RualStorge 9,5372231 · Answer 9 · 2015-02-13 16:11:25Z

A slight twist on "Write proper comments"

Good commenting is ALWAYS a plus. By all means anytime you do something unique, hackish, or otherwise not obvious it needs a comment. (Because anything odd probably needs an explanation or you'll wind up revisiting it for no reason other than "what the heck is this nonsense?")

Another thing that goes along way is SOLID design principal and writing "self commenting code"

SOLID design

The entire point of SOLID design is to break your code into it's smallest components to make each and every piece do one thing for testability and reusability.

This also has the benefit of making every piece of code REALLY simple where most of the time the method and variable names alone cover your needs for commenting. (there will always be places that could use additional comments, but the idea is to get it so the code itself is clean enough that you only need the occasional additional comments rather than needing them for every single method)

Self commenting code

Self commenting code is the idea of naming your methods, classes, and variable as such there is no question what's happening at a glance.

If you method is called "FinanceProcessor" you're going to need a comment... Okay... Finance is a VERY broad subject... perhaps a poorly named object? And what the heck am I processing?

Now if that same method is named "UpdateRemainingBalanceByUserId" okay, so that makes sense! I'm going to update the remaining balance based on whatever user Id I provide. I don't know the knitty gritty on how this works, but I now know what it does!

Now lets look at variables... bool payments, bool refunds, bool round, int UserId... Hmmm not very useful... I mean UserId is self explanatory thanks to the method name but am I including these bools, excluding, or something else?

Now if we made these variables... bool includePayments, bool includeRefunds, bool roundToNearestDollar, int OwnerId. Ahhhhh!!! that makes sense! Once again I don't really know how this thing gets it's data for crunching numbers, but I know what it's supposed to do and what these variable will do.

Summary
Adding comments is good, but making clean self commenting code (with comments where appropriate) is better! Cleaner code requires less explaining.

The goal is anytime you look at something in your code you should know WHAT it does without any further investigation, comments should only be necessary for telling HOW it works and little oddities that don't make sense at a glance.

Rajarshi Goswami 1394 · Answer 10 · 2015-02-13 07:13:09Z

up vote
1
down vote

That is why writing proper comments is very important . Heard somewhere " write code as if the next maintainer is a vicious psychopath who knows where you live" . Writing proper comments is a first step before starting code also, as it will enable you and whoever maintains the code to understand without going through the entire code

answered Feb 13 '15 at 7:13

Rajarshi Goswami

1394

Although comments and documentation are helpful, they only help with the first part - in the second part OP is in a meeting with his manager who is discussing features he implemented a week ago. He has no access to code, comments or docs.
â€“Â Konerak
Feb 13 '15 at 7:48

1

The manager asks him something and he will go in without any preparation? That's plain wrong. If the comments is good, he can just a glance at the comments with the manager or himself before going to the meeting to summarize everything or during the meeting also.
â€“Â Rajarshi Goswami
Feb 13 '15 at 7:57

Yes! You should add that to your answer - preparing for your meetings better, documenting what you did, how you did it and why you did it and making sure you can tell anyone anytime. This is not just true for programmers, but for most careers: always be ready to answer the question "what have you done for the company since you joined here?".
â€“Â Konerak
Feb 13 '15 at 8:07

-1 - Comments that say what code is doing are to be strongly avoided.
â€“Â Telastyn
Feb 13 '15 at 15:15

suggest improvementsÂ |Â

Search This Blog

Iyfjky

A career in programming for a forgetful person [closed]

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

5 Answers
5

5 Answers
5

5 Answers
5

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

A career in programming for a forgetful person [closed]

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

closed as off-topic by gnat, bharal, Jim G., IDrinkandIKnowThings, Garrison Neely Feb 17 '15 at 18:54

5 Answers 5

5 Answers 5

5 Answers 5

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

5 Answers
5

5 Answers
5

5 Answers
5