How do programmers keep it all straight?

[.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.