Occasionally, I’ll find a code snippet that solves a problem for me. While I may copy the approach to the problem, maybe even copy and paste a a block of code, I always end up with my own code in the end. In the case of copy/paste, I’ll do that because it’s easier to drop it in place and modify it out of existence or refer to it in my own code (then delete it) because it was too large or complex to commit to memory.

Other than that, I don’t “get” code from the internet. I get information from the internet.

Don’t forget, example code is great, but is almost always incomplete. It’s usually devoid of error checking, and likely is completely unaware of the context you are putting it in. That is a good reason to first understand the example enough to start re-writing it yourself.

Ask the other engineers.

Failing that - I start doing text searches on the entire source code looking for words that seem promising.

I’m a fan of command-line tools, and I use either Linux ‘bash’ or “CygWin” for windows…the “grep” and “find” tools are very useful here.

In C++, I also search the source code for any lines starting with “class” or “struct” and dump out a list of filenames and class declarations (curse you people who put “class” and the name of the class on consecutive lines - you are sick *SICK* people!!)

This gets you the overall class heirarchy of the package which lets you figure out the rough structure of the code quickly.

I sometimes use a huge whiteboard and cut up those filename/class-name snippets - then tack them up onto the whiteboard with magnets and connect them up with red string…kinda like you see on those crime TV shows where the cops connect up the photos of the bad guys to show who connects to who.

You can also use things like “Doxygen” to automate the generation of crude documentation….even if the developers didn’t add in the magic comments that Doxygen uses….you still get useful output.

But all of this depends on the code being fairly readable, with sensible variable, class and function names…you’re not always so lucky.

I once was handed a million line of code package written by a team of French engineers who had all been fired…figuring out our way around it was a total nightmare. It ended up being easier to rewrite than to understand.

The worst one (which I was mercifully not involved with) was when the company I worked for was paid by the US AirForce to take a five million line FORTRAN program - convert it to C++ and then get it documented and “under control”…those poor, poor guys.

I could write five books on this topic, but I’ll give you a couple of techniques.

Basically you look for a block of code where the variables of your program have their expected values before you get to the block, and have wrong values after. Then you examine the block of code line by line looking for your logic error.

You can print out the values of relevant variables by inserting print statements in the code, that you remove once you’ve found the error. If it’s a windows program you write to the debug console with OutputDebugString(), and run the program from the debugger. On linux, you write to the standard error channel.

If your program is broken up into many small functions, it’s easy to find good places to print. If it’s a long block of inline code, you just have to move the print statements down the code.

If you’re trying to diagnose a bug in flow-of-control logic, your print statements just say print(“Got to point xyz”) or “print(“Called function foo”) for different points in the code.

Depends on the project and code base, but often you just follow the breadcrumbs.

Say you’re working on a disk utility, and someone says “Hey, maybe we should have an “are you sure?” dialog before it formats the disk, rather than immediately wipe it?”

So you find the window with the “Format Disk” button on it, and see how that attaches to the code, it varies depending on what UI framework you’re using.

Find that code, and follow it until it gets to where it actually does the formatting, and put a “Are you sure?” dialog around it.

Many projects will be more complicated than that, and take more digging, but often you just sort of start where the user interacts or where the API is served or whatever and just follow it down.

The obvious answer is practice. However what makes good practice isn't obvious. but to elaborate…

The highest impact learning always feels like a series of “aha" moment. I look at the problem statement / learning material and go hmmm i think I understand about half of that. Then do some experimenting, re-reading, researching etc. And revisit the material and then it clicks eventually. If you're getting stuck for too long or you are completely stumped, or none of it makes sense… then it's probably too hard. Inversely, if you know the solution as soon as reading the problem, then you aren't learning anything. Find that middle ground of challenge and your ability.

Some quick take-away:

• learn to give yourself time and how to focus better, until you have learnt how to trigger your pattern recognition skills at will, even under stress;
• do not stop when you see a mountain, but start climbing a series of steps - every problem can be broken down into smaller sub-problem, which are much easier to solve individually - divide and conquer;
• read about a problem the sooner you can, then if you do not feel like solving at once, let it go and go for a walk or do something else - you will be surprised by how many solutions pop out of your mind when you less expect it: waking up, showering, hiking, etc;
• the best reward you can get for a solved problem? Reading (and learning from) other people solutions (CodeWars is awesome also for that);
• if you are finding either too many difficulties or no challenge at all, you are doing something very wrong: walk the path that keeps you with at least one foot out of your comfort zone;
• no matter how much of a loner you might be or how much you fear distractions: try to build your own entourage of people with similar interests and passions to share knowledge and motivation - even a small group of 3–5 people can work;
• do not get cocky as you progress, but consider what you could improve - keep a toBeLearnt list, if that helps;
• conversely, do not get crushed down if you have too many failures, as you can learn much more from them than from 1000 easy successes - consider revisiting problems you solved in the past, maybe struggling, and you would be surprised most of the times by how much you have progressed since then;
• learn something new constantly, even outside the not so narrow field of CS: good athletes do no train exclusively the muscles they use everyday, ignoring everything else;
• remember that, again as an athlete, merely exercising is only a part of your training: eat healthy, get good rest, give yourself some reward.

Hope this helps, happy learning and coding :)

This is a bit unclear, because “have access to” could be taken in several different ways. But I’ll answer the question assuming:

• You have the source code for the application
• The current version of the program is an executable distributed across many computers that you do not have access to.
• You have discovered one or more bugs in the application.
• You are able to compile, fix, and test the application, but the fix will not be distributed until the next release.

Since I’m assuming that you can’t fix the bug without the source code, you can find and potentially fix the bug “in house”, but that still leaves buggy copies of the program on customer’s sites for potentially months.

You have entered the grim and foreboding world of: WORKAROUNDS!

A workaround is something you can tell customers that will allow them to get value from the buggy program by modifying how they use it. Today it is possible to get fixes to users fairly quickly, but the updates probably need to be tested by the customer before being used. Examples of workarounds that I’ve experienced are:

• The input data must be less than 20 MB when using the dingbat option.
• The operating system must have Java version **** or later installed, to avoid crashing when displaying graphics.
• The glork option requires that the operating system be version xxx or later.
• When the locale is set to Iran several options are inhibited to comply with their laws. (These may be “features” that have to be turned off in certain locales).
• In the documentation, the example of setting the locale is incorrect for some systems, leading to the program crashing. The correct usage is …….

Workarounds can be very difficult to verify, since you are working with a program that is buggy and the bugs may expose other code that is questionable (e.g., perhaps left over from an earlier release).

As we move towards more cloud-based software, workaround technology will, hopefully, become a lost art… However, don’t hold your breath…

Define ugly please? Unmaintainable? Complex? Entangled?

To answer your question: as Da Vinci put it: “Simplicity is the ultimate sophistication”

It takes time and attention to simplify things (boil down) to its essence. Did you ever wondered how ants find their straight way to you leftover bread across a room? They iterate.

So if you think the return on invest worth the effort, you should iteratively try to understand the various pieces, what they do and how they fit together. Making small refactors and many small releases. (I do not expect to find unit test for ugly/unmaintainable code). Each iteration should add no feature, just extract one aspect, make some automated test and release and hope you did not broke something.

Sometimes you will, don’t worry you just learned something from your domain. Don’t forget the add tests to help the next guy.

Have fun iterating, you will need 7 rounds of rewrite to reach perfection. (At least this is the magic number from ants). You rarely have so important code that you can reach the perfection. And of course goals change, so you will probably fall back to square 1.

Does writing down probable codes for different problems in a hand note first, … increase the ability to solve programming problems?

I think this is a good idea when you are learning to code. Writing pseudocode allows you to ignore irrelevant details and concentrate on getting the structure right.

You can always throw away your scratch paper, but it is hard to do that with code that you have laboriously typed in. You always think “I can fix this” and then put a lot of effort into making a bigger mess.

You will find, as you gain experience, that there is less need to this at the detailed level.

Even now, I try to get the big picture clear in my mind before I start coding, and sometimes I even have to write something down. These days that will usually be some sort of system diagram (i.e. named boxes with lines between them).

I hope this helps. Thanks for asking.

Don’t think in term of how you would code it.

Imagine things being physical objects and how you would manipulate them. Drawings can help tremendously.

If it’s something computation centric, workout through few examples by hand and try to really understand what you are doing ! That’s not because you are doing something that you understand it ! (Yep, this pill is hard to swallow, isn’t it!)

Once you can explain intelligibly what you need to do to solve any occurrence of the problem, you are good to code it.

No stress, coding is damn fast if you only have to explain the solution in “programmatic terms”.

Eg.

Given a set of number, find which number can’t be paired with another to do a given sum. All possible pair have the same sum.

Example {14,24,6,29,8,21,11} odd one is 8.

Try to program a C solution for it.

Generally, you can’t. Usually, the original source code will be on a company’s server, locked away from public access. The application itself will generally be a compiled version: That is, it’s been turned into executable code that the particular host platform (Windows, Android, iOS, etc) understands.

Other answers have suggested the following options:

• Download the source: This is an option if the application happens to be open-source. If that’s the case, you can download the source, inspect it and even modify and re-build it to create your own version. With most open-source licenses, if you modify it you should then submit the modifications to the original code base.
• Reverse Engineering tools: If you happen to guess the original source language correctly, you might get something that looks vaguely like the original source code. It won’t have the original variable, method, file or function names and it definitely won’t have comments that might explain what was going through the developer’s head, but it will have at least similar structure to the original.
• Behavioural Analysis: This requires quite a bit of experience in development. If you know the way various languages behave in response to specific input patterns, you might be able to devise a version of the code that seems to behave the same way.
• Infrastructure Clues: One answer suggests that if the JRE is invoked, it’s likely you have a Java app. This is a good clue. As that answerer suggests, of course, it still doesn’t necessarily give you a clue about the original code unless you can convince the owners of the source to release it to you. On the other hand, Java is a byte-code compiled language, so you should be able to reverse engineer it pretty readily (again, without actually getting back the original names and comments).
• Inspect option: This may work for an HTML-based app.

First be aware that human memory plays tricks. All the code will not stick in memory, not even for the original programmers. I will bet that after 6 months the original programmers will not remember all details, and their minds are starting to play tricks. If they had a discussion on how to implement a module, everyone will have a different interpretation of what the inner workings do, and what limits they have. The advantage the original programmers have is, they know what has been built, they know some of the issues, and they know the overall architecture.

Getting to know a codebase well is mostly about getting a highlevel architectural view, and knowing the domain well enough, to figure out which modules exist, and where they reside.

Getting domain knowledge can be harder, but reading user documentation, requirements, usecases, and watching tutorial videos can get you to a certain point. And if possible, talk to users to understand how they use the software. Knowing how to read the code tells you how the guys who wrote it, decided to convert usecases to code. You look at the code because the previous guys did not complete it. So you will need to understand both what they did, and what they were trying to do. If you are building on their perfect bugfree foundation, you still need to understand what they did and how they anticipated changes that would come.

1. You need to have a good grasp of how to analyze the time complexity and space complexity of code. This is a very important skill as it provides you with a yardstick to compare one algorithm to another algorithm. Any basic course in data structures or algorithms will have heavy emphasis on this (if they do not have then I would think that the school's computer science programme is not good). You can try reading Introduction to Algorithms, but I am not sure whether you will be motivated enough sufficiently to read it entirely.
2. The next step is to equip yourself with commonly used data structures and common ideas to solve a problem and algorithms. Data structures like stack, queue, linked list, skiplist, hashtables, bloom filters, trees, binary search trees, balanced binary search trees, priority queues, union find, trie, suffix array, suffix trees, segment trees/interval trees, fenwick trees and so on. Concepts that you should experiment with: binary search (and ternary search, depending on circumstances) greedy, dynamic programming (Longest increasing subsequence, edit distance etc etc), complete search, heurstics search and so on. Algorithms you should know are like quicksort, mergesort, DFS, BFS, Dijkstra, Prims', Kruskal, bipartite matching, maximum flow stuff, graham scan, jarvis march and so on. I probably left out a lot of things but I guess the names here should get you started.
3. Practice. Alex Levin provided some resources to try algorithmic problems. To add to the list, you can try SPOJ, codeforces, codechef, uva online judge, and so on. Try searching for the archive of ACM ICPC regionals and world final problems too.

The above is a long list of things to read up on, and so I wish you the best of luck. Finally, as I am a good friend of Steven Halim, I will shamelessly advertise for his book: https://sites.google.com/site/stevenhalim/

PS: I just found this link: What do you think of Competitive Programming book by Steven Halim?

Thanks for the A2A

Look, I'll be honest that I haven't read any other answers here because I hope they all say pretty much the same thing:

Practice. To get better at anything you need to do more of it. Now Malcolm Gladwell produced this idea that 10,000 hours of deliberate practice are the bare minimum to becoming an expert on something. The Google search I did actually shows many results saying it's been disproved, but I haven't read any of those yet. Regardless of what they say, not practicing at all, so, just watching a lot of videos for instance, won't build the muscle and brain memory needed to be good. There's a proverb I've heard attributed to the “Ancient Chinese":

I hear and I forget, I see and I remember, I do and I understand.

I have seen that ring true in many aspects of my life, across many jobs, most of them not involving software at all.

Now when you're new and hopefully realising just how much you don't know (ie: you're starting to move out of the haze of the Dunning–Kruger effect - Wikipedia it can be a challenge to work out how to get some deliberate practice. For this I advise you think of something you wish your computer could do for you that it currently doesn't. If you can answer that, it's a start, the seeds of a useful goal. You then need to set about getting answers to questions to make your goal begin to take shape.

Another thing you could do is find something your wish you understood better and have a go at “inventing your own wheel". You have probably heard that reinventing the wheel is a bad idea but this is only true in a paid, production environment where recreating your own, untested, probably buggy version of something that already exists is a huge waste of time. Making your own wheels, however, can be a HUGE benefit to learning and practice.

For example, in my early days, networks fascinated me and I wanted to understand the protocols. So I wrote a lot of packet sniffers in C. The work to sniff the packets had been done by others using the Pcap library, so I just bolted that wheel on. The real understanding work came from reading protocol specifications and RFCs to know how to write my own decoders. Essentially I had to learn how to parse the protocols myself, and then how to put that in code. After I finished my own DNS resolver library in C I came away with an understanding of the layout of UDP DNS packets, what request and response records look like, how DNS uses simple compression to save space (which also lead to an understanding of why individual components of a domain name can be no longer that 63 characters). I also got some practice on writing libraries and then being on the receiving end of that library as a user of it. I also took the opportunity to learn how to write man pages, which is a Unix thing.

So in summary:

• You have to practice
• Find a goal to help guide your practice
• Never give up too early. One major difference between good and okay developers is perserverance.

Good luck on your journey and I hope you find it as fulfilling as I have.

First, you need to know how to reproduce this bug. If you can’t make it happen on purpose, then it’s “objection .. hearsay”. It’s hard to rely on someone’s memory of the bug without seeing it yourself.

Once you have that, you can do all kinds of experiments.

1. The delta experiment: You check when did that start to happen. So you check the previous versions (on git for example) until you find a version where it doesn’t happen. And now with the diff between this version and the next, you could tell where things went wrong.
2. The elimination method: You could start disabling parts of the code and run again. If the bug still happens, you could disabling other parts until it no longer happens. Then you could tell which components are involved in this. Of course it doesn’t mean it’s the one that has the bug. But it could be a component that prepares an input for the faulty component.
3. The logging method: You could print the inputs and outputs of each component or algorithm. And then run the application and reproduce the problem. Then check which component or part had a valid input but the output looks fishy. Zoom-in there and increases the logs to all sub components until you pin point to that one line of code causing the problem.
4. The search for leads: If you're not sure which component is causing the problem, you could at least figure out where to start. If there's an error message but it's vague, you could try searching for it in all the project files to see which module is outputting it. And then put a breakpoint there or log some data. Or if the problem happens when you load a certain kind of file, you could look up where are files being loaded and who's using a file loader or parser. Just by a text search. And then start from there. Put logs to spy on which one was active when the problem happened. And that would be your lead.
5. Using the debugger: if the problem is as simple as a crash or an exception, you can just run in debug mode with a debugger and it'll show you where it crashes with a stack trace. In some languages it can even print the stack trace.

Coding is one of those things that sounds a lot more complex than it is.

While that doesn’t mean that it isn’t complex, it’s a lot easier than it sounds.

On TV, they show hackers and programmers with their fingers flying across the keyboard, spouting technical terms that sound like scientific nonsense, beads of sweat forming on their heads as they “hack the mainframe” or whatever it may be.

This is what most people think programming looks like:

In reality though, this is what most programming looks like:

It takes a lot more thinking than actual typing. In most cases, you aren’t working against some kind of minutes-long timer like they are in the movies.

In most cases, programming is calm, and fun.

But let’s get to the question at hand.

I know lots of different programming languages. HTML, CSS, JavaScript, PHP, Java, BASIC, TI-BASIC, GML, Bash, and probably more that I can’t remember. I’m not actually all that great at all of those languages.

But how did I get to this point, where I’ve learned as much as I do about programming?

Time. Time and practice. Just like learning an instrument, or starting a new job, things will feel confusing at first. But over time, as you practice, you get better and better until it’s just natural.

There are a lot of resources you can use to start learning to program.

Online resources, books, tutorials, and all kinds of things.

I find that I learn best from interactive tutorials. Things that will teach you how to do something, and then lead you through completing a similar task yourself.

The website I learned on was Codecademy, but it’s been quite a while since I used it, and they might not be completely free anymore. If they are, then their web courses really helped me out. They teach you a concept, and then they lead you through actually performing that task on your own.

I didn’t really have an experienced programmer alongside me when I learned, but I imagine that, if someone had the free time for it, that might really help out as well. (Then again, some of us might not be the best of teachers. It depends on who you’re asking, I guess)

But the biggest thing that seems to scare people is the complexity and the time involved in learning it.

Take for instance, this little chunk of code…

Let me know if this is too easy of an example, but to an inexperienced programmer, this probably doesn’t make much sense.

But what about this way?

In each of the lines above that start with “//”, there is a comment that describes what that line of code does.

First it asks for their name, which is provided as one sentence.

Then it splits that sentence into two words, by cutting at the space.

Then, if the first letter of both names is the same, it tells the user.

Now, after you know what each line of code does, you should be able to go back to the first code and read it better than you could before.

Here, I give another image:

That is what’s called a Guitar Tab. If you’ve never played guitar before, you probably have no idea what any of this means.

But someone who has practiced with guitar tabs would know that each line is a string on the guitar, and each number tells them where to put their fingers.

Even though it sounds so simple though, it takes a lot of practice with a guitar to be able to play even such a simple song well.

Why did I bring up guitars when we’re talking about programming?

Because learning programming is just like learning an instrument.

It takes time and practice, and once you eventually get good at it, it’ll be loads of fun to do in your free time. Even the process of learning is typically fun in some way.

One more thing before I finish off the answer. Imagine yourself learning guitar. Learning to read the music, learning how to play and where to put your fingers. Now imagine that someone asks you to play the same song on a piano. It will take a lot of practice, but I imagine it would be a lot easier if you’ve already trained your mind to work with music, rather than when you first started out.

It’s the same with programming. The more you practice, and the more you learn, the easier it becomes over time to learn new languages and new concepts.

Taking a guitarist and asking them to learn piano, would be similar to maybe taking someone who uses lots of JavaScript and asking them to learn C. The instrument or programming language may be completely different than the one you already know, but because you have trained your mind into music, or programming, it will be easier to learn the new instrument or language than if you had started from scratch.

That’s why time and practice are so vital to learning programming. When you first start out, it might feel like progress is slow. But over time, as you learn more, it then becomes easier to learn even more. Progress will speed up, and before you know it, you’ll be making some big project, or having so much fun playing around with a new hobby.