I have studied numbers of errors caused by using the Copy-Pate method and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have never seen this phenomenon described in books on programming, so I decided to write about it myself. I called it the "last line effect".
You are so lucky to be a programmer. I would like to be the programmer.
- Why do not you learn?
- I already tried. I checked out codeacademy and other websites, but it is not mine.
- Yep, the programming is not really for everyone.
- You are well paid, and you can create different things. Almost every day you get some crazy offers at least for 100 thousand dollars.
- Yep, honestly it's very flattering and a little mind-blowing.
- You get your share in the company and you know that the software engineers are always respected. You can implement any idea in the app and get rich. Moreover, you do not need to hire anyone for this.
- Actually, the programming makes me miserable.
- Wow. What do you mean by that?
- In order to be a good programmer, I need to develop a special mindset and that makes me sad. I noticed this in other programmers, of course, not all, but in many.
- What is this mindset?
- This is concentration on the strengths, and not on the weaknesses.
- Why do you need this to become a good coder?
- I work like this:
I think that each of you tried to find the own way to solve tasks in the learning process of a relational database management system, and not knowing that out there are various helpful features, which could speed up the queries at times and reduce the code size. In this article I want to share with you my experience, namely how to work with MySQL comfortably, often allowing the programmer to do the things that other databases would not be able to do. This material would be useful rather for those who just decided to delve into the wonderful world of queries, but maybe the experienced programmers will find something interesting for themselves here.
Perhaps, this article may not present any new or fresh ideas, besides, I'm sure you have often read something like this somewhere else. This post even does not claim the fact to be true. Its content is the fruit of my own experience, mistakes, and the knowledge that I have gotten from my colleagues. I'm sure that many people will be able to find themselves in my article. Probably, the first stage is not very typical for the programmers who are not involved in the Olympic programming, but the following stages do not independent from this factor at all.
In this article I'm going to discuss a problem few people think of. Computer simulation of various processes becomes more and more widespread. This technology is wonderful because it allows us to save time and materials which would be otherwise spent on senseless chemical, biological, physical and other kinds of experiments. A computer simulation model of a wing section flow may help significantly reduce the number of prototypes to be tested in a real wind tunnel. Numerical experiments are given more and more trust nowadays. However, dazzled by the triumph of computer simulation, nobody notices the problem of software complexity growth behind it. People treat computer and computer programs just as a means to obtain necessary results. I'm worried that very few know and care about the fact that software size growth leads to a non-linear growth of the number of software bugs. It's dangerous to exploit a computer treating it just as a big calculator. So, that's what I think - I need to share this idea with other people.
A couple years ago, I worked together with Ken Thompson on the interactive graphics language that was developed by Gerard Holzman in Bell Labs. I was typing quicker, therefore, I sat at the keypad, and Ken stood behind me. We worked quickly and when the compiler gave out an error, I started reflexively digging in a problem, studying the call stack, program output and launching a debugger, and so on. But Ken simply was standing nearby and thinking, ignoring me and a code, which we just wrote. Soon I noticed regularity that Ken often understood the problem faster than me and was saying, “I know, what is going on”. Usually, he was right. I understood that Ken built the mental model of a code, and when something was broken, it was the error in this model. He was thinking of how this problem could arise, so he explained what was wrong with model, or where our code could mirror this model incorrectly.
I have little experience (summarily I have been working as a programmer nearly for 16 months), nevertheless, I would like to give some tips to myself in the past, or in other words, to those who are studding now at the university and planning to become a software developer. I do not have a claim on wisdom or experience on no account. While thinking a little, I understand that all these tips are very actual for me more than ever too. I published the first note in my blog last year, and now I am publishing here the list expanded with tips of the readers of this blog.
All tips are independent and their order does not matter.
I have recently gotten a web application from a nasty contractor who claimed to be a good expert in programming. Unfortunately, we believed him. Functional of the web application seemed to work okay at first glance. However, once the client started using application in the real conditions the things went bad. The contractor has gone after a payment, and I have gotten his errors to fix for a client.
I decided to document a few errors that I found along the way. These are errors that every good programmer should already know to avoid… but obviously some people need to be reminded about them.
1. Learn a new programming language
Learning the new programming language will develop new ways of thinking, especially if the new language uses a paradigm that you do not know yet. Many of the acquired ways of thinking could be applied to the languages that are already known. Perhaps, you might even like the new programming language, and you will start using it for new serious projects.
Here are some good languages that give the great educational experience and cognitive effect: Lisp (Scheme is good), Forth, PostScript or Factor (stack-oriented programming languages), J (wonderful array programming language), Haskell (strongly typed purely functional programming language), Prolog (logic programming) and Erlang (concurrent programming goodness).
2. Read a good programming book
A lot of knowledge could be found in the books. Undoubtedly, a practice is also important, but reading one challenging programming book might help you to challenge your thinking and to enrich your knowledge. Here is a list of such challenging books: The Art of Computer Programming (if you want a real challenge), Structure and Interpretation of Computer Programs (SICP), A Discipline of Programming or the famous dragon book.
Of course, you can read less complicated books as well, but you try to go around books such as “For Dummies” that promise to teach you in 24 hours or 3 weeks. These books will not do any good for you in terms of improving programming skills.
Here are 50 best quotes of famous people where you can find answers to most questions that you have.
50. Today programming is a race of software developers who want to write better idiot-proof programs and the universe that is trying to create bigger and better idiots. For the present the universe is winning.
- Rick Cook
49. Lisp is not the language, and it is the building material.
- Alan Kay
48. Walking on water, and developing programs, following the specification is very simple ... if they are frozen.
- Edward V. Berard
47. They do not make bugs like Bunny (Bugs Bunny).
- Olav Mjelde