How do programmers keep it all straight?

[rcgldr]

I'm an old timer, so my learning process involved Fortran, assembly, Cobol, APL, C, Java. In the olden days, the WatFor Fortran compiler was debug oriented, and could print out what line and variables were involved with an error. Fortran and C were the easiest for me to learn. APL is the most complex language I've learned. For Java, I use NetBeans for the IDE, which to me is similar to working with Visual Studio for C / C++ / C#.

That can also provide really important lessons that most beginners never think of and most old timers really should have learned: Predict where the bottlenecks in your application are, and then go try to prove your predictions correct. You won't, because your predictions are wrong.

For most of the projects I worked on dating back to the 1970's, the teams did a pretty good job of predicting and later confirming where the key bottlenecks would be. Most of these involved multi-threaded applications and/or operating systems, some of the early ones were multiple (mini) computer applications.

 

[gradev]

The answer to the original question ('How do programmers keep it all straight?') is simple: they (we) don't. We try, sure, we plan ahead (at least we should), and in the end we get it right (at least we should), but I've seen ghosts, if you get my meaning ;)
Making software is a process, and the tech is so huge, there are so many options... you can't remember everything everytime. But you don't need to remember every key command, every data structure and every [type here any word]. You just need to remember the what/why/when of conditions, loops and values (variables, constants, pointers... that doesn't matter in this ethereal scenario) and understand your requirements and goals.

Before you ever sign up for a programming class, take a course in Logic.

I agree. Logic is the most important thing.
Every language (Java, C#, c++, ASM, perl, PHP, QBasic...) is basically the same if your logic mind is working. Command names may be different, a for-next loop could be optimal using one language and a bad idea in other cases... You should focus on that kind of thing for every project, and let go after that.
The more you use a technology deeper will be your understanding of it, of course, and that's a good thing, but if you try to remember everything about it when you are not using that technology... well, you will forget about your real target (to make good/useful software) and that is the worst nightmare possible for you and your peers.

Python doesn't just take the opposite approach, it actively hides common mistakes from you

So true...

Personally if I were going to teach someone it'd be Java and Eclipse. They're free, well documented, supports most modern language features, and not only do your resulting apps run on any platform, your development environment runs on any platform (Eclipse is java based and runs on Linux, Windows and Mac)

I'd add c#, because now you can use it in every platform (Win, Mac, Linux, IOS, Android...) and Visual Studio Community Ed is my favorite free IDE. But Visual Studio doesn't work in Linux (although there are multiplatform IDEs for .Net languages).

 

[rootone]

In principle, programmers should thoroughly document every function and the meaning of the variables and constants in it.
In practice that doesn't happen much, because they are under pressure to get a job finished.

 

[harborsparrow]

You all might think it is a silly question...there seems to be so much to learn then more added so I switch and get very confused about even where all my files are.

I have been a programmer for decades and used many languages. My memory isn't any better than anyone else's, but I do a few things to supplement matters:

1) Get organized with files, and keep ALL old code you ever wrote. You'd be amazed now useful it can be to look back on how you did that thing LAST time, even in a different language.
2) Get a web server, and install a personal wiki. I use pmwiki because it's drop-dead easy to install on either Linux or Windows. In your wiki, make notes on how to do particularly tricky or common things that you want to remember. For example, I have a page specifically on T-SQL (for Sql server); I can't remember SQL code all that well, but I have marvelous records, so I can refresh my memory pretty easily.
3) Blog when you solve a sticky problem in any language. Somebody else will have the same problem, and thank you for posting the solution. And when you go for job interviews, they'll find your blog and love it. Plus, we all benefit from everybody else's blogs.

Programming gets easier, because like anything else, over time, you've seen it all. So be patient with yourself. I used to live in terror because I had to use so many different languages and operating systems, so I was never your deep expert. But working across a broad swathe of languages and technologies is also an asset--if that's you, embrace it. And take good notes. Get a wiki. Save all code. Blog. And try to enjoy the endless learning curve that is programming.

 

[.Scott]

In principle, programmers should thoroughly document every function and the meaning of the variables and constants in it.
In practice that doesn't happen much, because they are under pressure to get a job finished.

No, not every variable.
The most important thing to include in the documentation in a function prologue is an answer to the question "Why did I write this program?". The most important thing to document within the code are all of the special things that you are programming around. For example, if you are using a bin sort, why did you choose that method? For example, perhaps you want to keep the execution time within O(n) and so say why you are doing that?

Variables do need to be documented - but not all of them. If you have an array "CRabbit Rabbits[MAX_RABBITS]", and you are indexing through it "for(nRabbit=0;nRabbit<nNRabbits;nRabbit++)" and then you have a a pointer "CRabbit *pRabbit" and the first statement in your for loop is "pRabbit=Rabbits+nRabbit", none of those variables need further documentation. Anyone maintaining this code can go to the CRabbit module and discover everything they need to know about the CRabbit class. You may want to include something about how the objects in you array are constructed.

The purpose of the inline documentation is to help yourself or another programmer maintain the code. Your audience is someone who is a programmer capable of maintaining the code - not a layman.

I see tons and tons of code that meet a standard for documentation that is pro forma and utterly useless. The documentation should be bone fide communication of exactly the kind of information it will take for a programmer to thoroughly catch on to what is going in.

As far as there being pressure to get the job finished - software engineers get to say when they are finished. You don't have to hand your code in when it is not complete.

 

[.Scott]

keep ALL old code you ever wrote.

Assuming, of course, that you are allowed to.
Most of the code that I have written has been either classified, proprietary, or both.

 

[rootone]

As far as there being pressure to get the job finished - software engineers get to say when they are finished. You don't have to hand your code in when it is not complete.

That may be the case for serious science and engineering systems, at least I sincerely hope it is.
My own of experience programming for the commercial sector is that very often the client just wants something that 99% works.
I had a chat with with somebody on the the marketing side of the fence, and his attitude was, (nice guy mind you), that.programmers are hired to get a working result as soon as possible, as opposed to them fiddling around trying to make things perfect.

 

[symbolipoint]

THIS really does make sense!

That may be the case for serious science and engineering systems, at least I sincerely hope it is.
My own of experience programming for the commercial sector is that very often the client just wants something that 99% works.
I had a chat with with somebody on the the marketing side of the fence, and his attitude was, (nice guy mind you), that.programmers are hired to get a working result as soon as possible, as opposed to them fiddling around trying to make things perfect.

Not to specify any particular industry or field, but some companies focus on shipping products, and others focus on good, reliable development, before shipping products.

 

[Mark44]

My own of experience programming for the commercial sector is that very often the client just wants something that 99% works.
I had a chat with with somebody on the the marketing side of the fence, and his attitude was, (nice guy mind you), that.programmers are hired to get a working result as soon as possible, as opposed to them fiddling around trying to make things perfect.

"Perfect is the enemy of the good."

Not to specify any particular industry or field, but some companies focus on shipping products, and others focus on good, reliable development, before shipping products.

Companies are generally in business to make and sell a product, so there is naturally a tension between shipping the product and making it perfect. If the balance is more on the shipping side at the expense of quality, customers are likely to be unhappy, and opt for a different product. If the balance is more on perfecting the product, the product ships later, possibly losing money for the company.

 

[harborsparrow]

...programmers are hired to get a working result as soon as possible, as opposed to them fiddling around trying to make things perfect.

The expressed attitude, unfortunate in my opinion, is common in the software industry among people who do not themselves have much experience writing code. Also unfortunately, such folks sometimes end up managing those who DO write code.

We can all agree that producing working results in a timely manner is important--but it is not the only valuable thing. Overemphasizing quick results has risks, such as: (1) inadequate performance when usage ramps up, (2) buggy code that is difficult to fix, and (3) code that is difficult to improve, add to, or enhance.

I've had my current job for ten years; before me, there were a half dozen students who stayed for one year, wrote a ton of code "quickly", and then left for a higher-paying job. I estimate that I had to rewrite about 80% of the code which I inherited from those "fast" programmers. My boss never agreed to this, but I understood what he really needed--which was, for stuff for work, be stable, and be able to be modified and grown. He never thought I was fast enough, but overall, he was satisfied with my efforts. I did for him what was necessary (in this case, rewrite with better designs, better coding standards, and sometimes in a different language, replacing old third-party components that, while working "quickly", were not upgradable over time).

"Fiddling around" is simply NEVER, in my opinion, the way one gets software to be good. Use of appropriate, modular designs, good coding practices, good testing, and adequately understood requirements--in other words, planning and preparation in the early stages before most "results" are available--are IMO often necessary to get decent working software.

Remember the Obamacare website fiasco? That is what one risks from working really fast. The people who replaced it with something that worked also did really fast work--BUT they had the benefit of the requirements and preparation of the first attempt.

 

[S M]

The most important parts of computer programs are the algorithmic parts. Simpy programming because you can type commands will not be very useful. The more you understand the underlying theory, the better. Every computer language you use will be based in some way upon computer theory, including its structure, syntax, semantics and functionality. If this sounds too time-consuming you can see for yourself that you cannot get far in a casual manner.

 

[QuantumQuest]

In my view and according to my experience, the only things required for a programmer to keep it all straight are love for the job and organization. So, we basically talk here about good, efficient programmers. This distinction nowadays is more necessary than in the past because many people have rushed into the programming profession the last decade or so, motivated by the paying rates and based on mixing and matching premade things and do the job "fast" and "furiously". Of course the ever increasing need of more complex and more efficiently working software, which must on the other hand be modular, easily configured, modified and adapted and the ever increasing abundance of software online in any form, created the conditions for this. While it is a good thing for a society to create new job opportunities in the market, this on the other hand has tainted the programming profession and created various consequences, not the least of which are unmaintainable - or hardly maintainable at best, code, efficient programmers that they are not allowed to do the job in the proper way and - unfortunately in many cases, even not finding a programming job. Although this varies among sectors and fields and among countries I think that it is the common denominator globally.

Now, for a decent, efficient programmer, the qualities and skills to keep it all straight, with "all" growing on a day by day basis, develop through application of good principles - solid background of the basics of programming, perseverance, lots of hours spent, being broad minded, chasing bigger projects - job challenges and very importantly learning from his / her own mistakes and don't repeat them. There is a whole lot of mistakes especially for a beginner programmer to do, so he / she - at the very least, must not do the same mistake(s) over and over. In the solid background of the basics there is a whole lot of CS things that a programmer must have under his / her belt, with utterly important a good, sufficient knowledge of algorithms and data structures, among many other things. At a practical level, he / she has to be able to work even with the modest tools that do the job and learn new IDEs / tools, frameworks etc. fast. All the above things that a programmer must do / exercise have to do with a real love for the job. The other part is organization. High level concepts, methodologies, models and - at the practical level, code including templates, self - made libraries / frameworks and any other relevant thing, must be kept organized and mixed and matched appropriately. Programming, may not be anymore a matter of art as it was in the past but there is still some art in it which is not so of a "hard - wired" talent in my opinion, but love for the job.

 

[martix]

It's a craft, like many other endeavours of human experience.

The minutae of keeping what you are doing at the moment straight in your head is all about layers and layers of abstraction. You focus on one small task at a time. And then you package up that in a function/module/etc. and move on to the next thing and forget all the details of how the last one work - you just need to know it does. A construction worker doesn't need to know the intrinsics of how his electric drill works to utilize it properly and efficiently.

The meta part of programming - i.e. the stuff that does not involve actual typing of code is foremost knowing the right tool for the right job - just like a carpenter should know what tool to use for each wood so he doesn't damage the material or his equipment. In software it's a bit worse, since our tools change so fast. This necessitates an attitude of being open to learning. Plus various other habits that help working in teams, communication skills, etc.

 

[rcgldr]

I have a set of text files, documents, copies of web pages, and example programs to keep track of algorithms, language specific and hardware specific nuances. In the case of a complicated algorithm new to a group of programmers, companies usually acquire documentation and/or hire a consultant to teach the algorithm.

There's also the research aspect. For example, a group of companies fund UC San Diego's CMRR (Center for Memory and Recording Research), which is a relatively large university research group to develop new methods and algorithms related to that part of the industry.

 

[SixNein]

You all might think it is a silly question, but I have the impression that one should be able to somehow know the entire string of commands, and so feel overwhelmed and defeated. I never really earned the basics, just eased into computer work while in the healthcare field and have been struggling ever since. There seems to be so much to learn then more added so I switch and get very confused about even where all my files are.
Don't really have another question. Thanks if anyone feels like commenting.

I generally don't focus on details like commands up front; instead, I start by identifying and understanding the problem. Afterwards, I create a plan for the solution. Finally, I worry about those commands. It's pretty much the same concept as found in mathematics.

 

[brainierthaneinstein]

Even the most experienced programmers have reference books they use. Take time to learn the basics :) Once you have the core programming concepts down you can apply them to any language and the rest is just learning syntax.

Agree - I've got nearly 40 years programming experience, at the stage now where I can learn a new language in a few days. It comes to anyone with a the right mind and a little practise

 

[Ben Gilliam]

Before you ever sign up for a programming class, take a course in Logic. That is an essential fundamental that programming is built upon (and for that matter, good written and verbal communications too.)

 

[symbolipoint]

Before you ever sign up for a programming class, take a course in Logic. That is an essential fundamental that programming is built upon (and for that matter, good written and verbal communications too.)

Beginning programming courses seem to not have a course on Logic as a prerequisite, but the necessary logic is introduced both in the beginning programming course and in one or more of the prerequisite courses, such as in Algebra 1 and Algebra 2. Students (at least some of them) are not accustomed to using that logic.