Coding is easy, but programming is another matter.

There was a period in my life when I was just starting to do programming. I then thought: “Programming is so simple ... Why do people specially go to learn this?”, But with experience and education it came to understand that programming is a difficult thing.



Either programming is easy, or I just don’t understand anything. MemeGenerator.net

Evaluation of their success has always been important to me, because in the long run it does not matter what the others think, it is important what you think about yourself. Analyzing my experience, I reflected on the strengths and weaknesses, education, practice and personal growth. This process allowed me to learn new things and reflect on what it means to be a programmer.

Coding, programming and knocking keys

Most of the time at my first job in technology, I devoted HTML, CSS, and JavaScript. I made the elements behave in one way or another or weave visual plots with their help. At that time I did not think of myself as a programmer, and I did not want to become one then. Only some time later, when I realized how to do other things in NodeJS, PHP and MySQL, I began to consider myself in that capacity. Disturbing thoughts of all the great things in programming in my head, I got my first job with the “programmer” title “software development engineer”, in the framework of which I daily and actively solved various problems.

“Experience taught me that all this time I actually only frantically knocked and hit the keys, not programmed”

Programming requires a thoughtful approach and understanding of various types of data, structures, as well as technologies for the maintenance of which programming languages ​​were invented. The difference lies mainly in the choice of the process that is used in work on specific tasks. I focused not on data types or algorithms, design patterns, performance, or anything else related to the quality of code and applications. Instead, the emphasis was on the working mechanism and its aesthetic component, which often led to the birth of huge indomitable monsters. This was accompanied by feverish testing of the output until the result began to at least look a bit like a feature. All this gave me some feeling that I was doing programming,

Thinking about data

Data structures are an area thanks to which I realized how much I lack education. The basic idea is that you have various ways of storing, calling, sorting and searching data. When I just started programming, I never thought about the various tasks of working with data and performance when working with certain types of data. Very often, I used arrays by default (including hashes, json, dictionaries, and other terms for data sets with access by field names) whenever I needed to save the set, sort it, or process it in a loop.

The sets, stacks and queues seemed very interesting to me from the point of view of computer science, but when it came to putting them into practice in Ruby, my enthusiasm decreased. In my understanding, stacks and queues are one and the same. They allow you to get information from different ends of the data set. The only difference between queues is that in them you can only get the object added first. Having got acquainted with these concepts, I imagined them as putting objects on the processing list, which in theory allows reducing the load and sending non-urgent tasks for background execution. However, a practical application in a high-level programming language such as Ruby looks almost pointless, since the whole process, in essence, is pushing elements into an array or changing the position in it.

For example, you can implement a Ruby stack using this simple code:

class Stack
  # init stack 
  def initialize
    @set = Array.new() 
  end
  # put a new item at the end of the stack 
  def push(x)
    @set.push x
  end
  # get the last item in the stack
  def grab
    @set.pop
  end
  # is the set empty true false bool 
  def empty?
    @set.empty?
  end
end
# implemented stack 
s = Stack.new
s.push 'a' 
s.push 'b'
s.push 'c' 
s.inspect # 
puts s.grab # "c" 
puts s.grab # "b" 
puts s.grab # "a" 
s.grab.inspect # nil

With queues, everything is about the same in terms of the types of data created. In addition to this, Ruby has its own class for queues:

# ruby Queue Class 
q = Queue.new
q << 'a' 
q << 'b'
# Tests Examples using Queue 
puts q.length  # prints 2 
puts q.pop # prints a
puts q.length # prints 1 
puts q.pop # prints b 
puts q.length #prints 0

Despite its simplicity, in fact, we have before us an ordinary array. This certainly has its own beauty. In general, I can imagine their potential benefits in command line scripts, but otherwise it’s hard for me to figure out where else they can find application.

The binary search trees are of genuine interest to me because of the optimization of the search time, which they allow to achieve and the speed of obtaining the selection. In practice, I often easily retrieved data from arrays, but as the size of the array increases, searching for it begins to take a lot of time. This is where the binary search trees described in this cool video come into play.Harvard. And although I have not yet had the opportunity to use them in practice, I really want to try to do this in a real project to compare this algorithm with the native methods of working with arrays in Ruby and see how fast binary trees will work compared to regular arrays or hashes. In the course of studying them and trying to find ways and scenarios for their application, I found these interesting articles:

• Searching with string - sample code on github gists by yuya-takeyama
• Searching numerically by Zach Kemp

Convenience of escort

My first web application was written very badly in terms of ease of maintenance. I completely did not use any design requirements, design patterns, methods for defining methods, namespaces, objects or models. If I had to go back to the code to fix bugs (which, I am sure, are there), it would probably be easier to rewrite everything from scratch than to try to determine the method that causes the bug.



Bad design breeds spaghetti code. Spaghetti code breeds misery

One of the problems that I found difficult to solve was nested conditional statements and loops. In such cycles, there is often a whole wagon of if-statements and checks, but this problem actually arises from another - a misunderstanding of how to properly organize and separate the various parts of the program. I tried to execute everything in large methods and did not pay attention to the individual components that could be reused or created as modules that extend the functionality of all objects or methods. Below is a real piece of the program, shortened and modified to save space.

print " 
 Display Weekdays: 
 ";
// Looping in a view ... should have been factored diff
foreach($imageRecords["display"] as $ => $displayRecords) {         
     // WTF is this a nested foreach 
     foreach($displayRecords as $value => $dispRecord){
       $tempWeekdayValuesArray = array();
          if($value === "weekdays" && !isnull($dispRecord)) {
             // 3rd nested foreach WTF!
             foreach($dispRecord as $weekday => $weekbool) {
                 // :( condition foreach day ::SHAME::
                 if($weekday == "monday" && $weekbool == 1) {
                    // logic removed 
                  }
              }
           }
      }
}

I'm certainly not going to shift the blame on someone else. This code was written by me, and I am responsible for it, but everything could be better if I had a mentor, the ability to send the code for review or pull requests. Today I am ashamed to look at this code, but there is a positive point, as this indicates how much I have grown as a developer. Mention should also be made of the freedom and limitations that I have encountered. For this project, I was forced to work on the LAMP stack, and this question was not subject to discussion. At the same time, this was the only limitation. I did not need to use design patterns or statistical analyzers and follow any style guides or policies on the code format. This creates a system in which the developer is free to do whatever he sees fit,

Over time, I began to truly appreciate text editors and the time savings they provide by analyzing potential errors in the code as it is written. But besides that, I also began to appreciate other smaller, programming-related details. A well-written code base that follows documentation standards, clear requirements, and style guidelines can also be read fluently and simply as an e-mail or online article (provided that the programming language sometimes used alone contributes to this). In general, I also realized that I really like the many principles described in the Clean Code A Handbook of Agile Software Craftsmanship by Robert Martin and other authors.

Test Development

The advantages of development through testing, in my opinion, speak for themselves, but I understand that not everyone agrees that testing carries any value for the code base. I will not argue about the validity of testing, but I want to share with you how it helped me. Writing integration and unit tests for the code even before its actual creation provided me a lot of help. This approach allowed me to write cleaner code, to do it more efficiently, and to cope with tasks, the solution of which makes me difficult.

Writing cleaner and more efficient code is at the crossroads of many other good programming practices. Development through testing, in particular, helped me improve readability, performance, and writing speed. I found that I learned to write code that does not need to be redesigned (or needs much less) before being sent to a production or version control system. Testing helped me not only reduce the number of bugs, but also the amount of time that I spend on tracking and fixing them. I found that during the correction of the bug I can take the expected input or output, write the appropriate test, and make sure that this and all other tests start to give the correct result. This allows you to eliminate the bug, while the code continues to do what it should.

Development through testing helps me streamline my thoughts before writing methods or objects. In cases of writing more complex features, it helps me break it down into the minimum set of elements that is necessary for its correct operation. Often it reminds me of the usefulness of writing pseudo-code, because current tests sooner or later lose their usefulness and need to be changed as the code develops. However, in general, borderline cases are borderline cases: it is much more difficult to think through them in advance when creating the code. The bottom line, I believe that development through testing helps me as a programmer to grow.