How to start a career in coding

A couple of days ago, a good friend of mine asked me how to make her kid more interested in programming. I think that parents should focus on giving kids opportunities to try different things instead of pushing them to take a route. Success is guided by motivation, and motivation comes from the inside. The best programmers I know started and continued their careers because they enjoyed the craftmanship of coding. They were attracted to the cryptic look of a screen full of code. They liked the tactile nature of typing code on a keyboard. They were amazed by how a series of words in English mixed with special characters lead the computer to show something on the screen. They quickly grasp the idea of a series of steps typed in a text file and how the computer understands these steps and executes them. They early discovered that the computer is, in the end, a dumb machine that obeys the programmer. None of them told me something like, "I started to program computers because I knew I would have a job in the future." No. The motivation is in the craftsmanship.

Like with many other disciplines, you can try programming and see if you like it. I started when I was about 13 years old. Since it seemed my brothers and I liked computers and we had gotten our first one, my parents bought a series of books on computers for kids. The third book was about programming. The programming language that the book explained was BASIC, a general-purpose language with an easy-to-read syntax. I don't think you need to be a kid or a teenager to start a career in software development. All you need is to experience coding by yourself and be honest with your feelings. If you enjoy the process, you'll get trapped in it and your curiosity will guide you.

So, let me show you how you can try coding by using the BASIC programming language. Unlike in my days of learning how to program, you don't need to install anything (lucky you!). Head to https://www.jdoodle.com/execute-freebasic-online and follow the rest of this article. This won't work if you don't go and open that page, preferably, from a computer (as opposed to a mobile device).

What you see on the website I pointed you to, is a screen divided into several sections. On the top, you have a text editor where you'll be typing your code shortly. At first, you'll find a short program already typed for you. Remove all that. Select the text and hit the delete key on your keyboard. We want to start coding from scratch! Next, you'll see a section to configure things out. I want you to make sure that you turn the "interactive mode" on by clicking on the switch that says Interactive. The switch should be turned to the right. Next, you'll see the area where the result or output of the program is displayed.

A programming language consists of words. Very few words actually, especially when compared to a human language. We are going to use upper-case for those words that are part of the BASIC programming language. For the rest, we'll use lower case. Let's get started! Type the following on the code editor at the top of the page:

PRINT "This is my first program ever!"

Click on the Execute button. You'll see the text "This is my first program ever!" on the output. Try adding another line of code to make the program show the message "I'm coding!" in the output.

PRINT "This is my first program ever!"

PRINT "I'm coding!"

Remember to click on the Execute button every time you want to see the result of your program. You'll see that the output shows the texts in the order in which you typed them in the code editor. Try switching the lines of code:

PRINT "I'm coding!"

PRINT "This is my first program ever!"

Once again, the output shows the messages in the same order as your instructions. The computer executes each line at a time from top to bottom. Let's try an essential concept in programming—variables. A variable is a space where you can store a value like a number, for example. A variable has a name and you are free to use any name as long as you don't use a reserved word like PRINT and others. Define a variable to hold a number by inserting a line of code at the very beginning of the program:

DIM n1 AS INTEGER = 7

PRINT "I'm coding!"

PRINT "This is my first program ever!"

The line you added tells the computer to create a variable with the name n1 and store the value 7 in it. The variable is ready, so you can make the program tell its value:

DIM n1 AS INTEGER = 7

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT n1

When you run (another term for "execute") the program, you'll see the number 7 in the output. Imagine that the variable n1 is the computer's favorite number, so you want the computer say "I like the number 7". You can just use PRINT "I like the number 7" but that's boring. Instead, let's use the value in the variable n1. To do that, you need to add the value at the end of the text "I like the number ". To do that you can use the ampersand character (&):

DIM n1 AS INTEGER = 7

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT "I like the number " & n1

Run the program and see how the computer tells you the number it was programmed to like. Change the value of the n1 variable, and rerun the program. For example:

DIM n1 AS INTEGER = 4

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT "I like the number " & n1

A cool thing about variables is that they can store values you can type when running the program. For example, let's make the program ask you what number you like. For that, you can use the INPUT keyword of the BASIC language. We need three new lines. One for telling the computer that we need another variable (to store your answer), one to ask the question, one to get the input from the keyboard. Add them at the end as follows:

DIM n1 AS INTEGER = 4

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT "I like the number " & n1

DIM n2 AS INTEGER

PRINT "What number do you like?"

INPUT n2

Run the program and answer the question! Type a number and hit ENTER. The instruction INPUT n2 tells the computer to pause the execution of the program until the user (that's you as well since you are the programmer and the user of your own program!) types a number and hits the ENTER key. The value that the user types is stored in the n2 variable. Now you can use the value to show another message to the user:

DIM n1 AS INTEGER = 4

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT "I like the number " & n1

DIM n2 AS INTEGER

PRINT "What number do you like?"

INPUT n2

PRINT "Cool, I also like " & n2

A powerful thing computers can do is compare things and execute code if a condition is fulfilled. For example, let's say you want the program to show a message if the number that the user introduces is greater than 999. You can do that by using the IF and THEN keywords:

DIM n1 AS INTEGER = 4

PRINT "I'm coding!"

PRINT "This is my first program ever!"

PRINT "I like the number " & n1

DIM n2 AS INTEGER

PRINT "What number do you like?"

INPUT n2

PRINT "Cool, I also like " & n2

IF n2 > 999 THEN PRINT "It's a big number!"

The last line checks whether the value stored in the n2 variable is greater than 999 and shows a text in the output if so. Otherwise, the program won't show the message. Run the program and introduce a number like 1000. Try also entering a small number and see the different behavior of the program. You are making your program look smarter and smarter!

I'm going to leave it there for now. Did you enjoy the experience? Was it fun to type code, click the Execute button, and interact with your own program? This is the essence of what a programmer does, and if you had fun and cannot wait to type more code, you are on the route to becoming a programmer! If you found it tedious or hard to understand, it might have been my teaching methodology that doesn't suit your learning style. Try other resources, like videos or books, and reevaluate your experience.

There are many programming languages. It doesn't matter which programming language you want to learn. You can continue your journey with BASIC or jump to a language such as Java, Python, C++, or any other that you find interesting for whatever reason. I recommend you get a book on the language you pick and read it through. Code small programs to understand the concepts or if you have a fun or funny idea, go ahead and code it!

Once you feel comfortable with a programming language, explore the libraries that are available for it. A library is code that someone else has written to fulfill a particular function. A library can include code for making it easier to render graphics or images, store data in files, show input controls like text fields and buttons, run complex financial calculations... The list goes on and on.

At some point, you'll have to learn concepts such as data structures and algorithms. Make sure to study the basics of these two topics as well. Read about software engineering. Learn about unit testing and source code control systems such as Git. But don't worry about these things when you are starting. Bookmark this article and come back as you progress. I really hope you continue your journey and, most importantly, that you enjoy it! If someday you get a job as a coder, let me know! I'd love to hear your story.

Read More

Copy & Paste Based Development

This is about Mr., W. J. a nice and friendly developer working for an IT company in a cosmopolitan city. He was in charge of five other developers. I was one of them.

It was probably my second day in the company, and he assigned a programming task to me. I was working on it, trying to figure out what the heck was that software I was going to help maintaining for the next months all about. Then, Mr. W. J. wanted to borrow my brain for a second. I wasn't using it, so I lent it. "Do you think this is a good implementation?" Mr. W. J. puzzled asked while looking at the screen, then to my face, back to the screen, then to the infinite. "Ummm... I'd say..." I managed to merely bubble when he interrupted. "I think I can also do this..." he said and immediately started to select a whole class with a hundred lines of code or more. He copied the code. He pasted the code. He pasted it in an empty file, slightly changed the name of the class, and made some modifications in a couple of lines. He ran the application, tested something on the screen, and said "thanks" without any traces of irony.

I couldn't resist my curiosity. "So... are you committing that code?" I puzzled asked while looking at the screen, then to his face​, back to the screen... "Yes!" he quickly replied without giving me the chance to look to the infinite. I thought it would be a Good Thing™ to explain him that Copy & Paste Driven Development™ is a Bad Thing™ sometimes. Explaining to a junior developer why that technique should be avoided is not the same as explaining it to your manager*, so I decided to tell Mr. W. J. a story about copy & paste in software development.

"It's funny," I started saying. "Some years ago I was working in a company and did something like what you did," I continued. "I copied a big portion of code, pasted it somewhere else and made a small adjustment," I added. "I didn't realise my boss was there when he poked me in my shoulder and said «don't do that again»," I convincingly finalised**. "Why did he say that?" Mr. W. J. puzzled asked while looking at the screen, then to my face, back to the screen. "I don't know..." I defeatedly replied while looking at the screen, then to his face, back to the screen, then to the infinite...

* It highly depends on the manager and the junior developer in question.

** I switched roles while telling this short story to be more empathetic with Mr. W. J. Did you think I was a copy-paste maniac? I think Mr. W. J. was. I saw him copying and pasting identifiers that were 2 or 3 characters long sometimes.

Read More

Semantic coupling

Code Complete is one of those books every developer should read. There is a section in chapter 5 of this book which talks about coupling. Although coupling between software entities is not totally avoidable in all of its flavors in even simple programs, there is a special kind of coupling that we developers should all condemn: Semantic coupling. According to Code Complete:

"The most insidious kind of coupling occurs when one module makes use, not of some syntactic element of another module, but of some semantic knowledge of another module's inner workings"

I have written some semantically coupled code, I must confess. Not a very shocking confession, though. I have found out that pretty much all the developers I have worked with, have semantic coupling in their criminal records. With the aim of making the programming world a bit more lawful, let me show you two basic examples of semantic coupling I found in my own code:

Disclaimer: Class and method names have been changed to protect the author's customers and the author's customers' customers.

Example 1. Avoiding calling a method because another method does it.

class SomeUIComponent {
  public void init() {
    setSizefull();
    ...
  }

  public setSizefull() {
    ...
  }
}

class AnotherClass {
  public void smartassMethod() {
    SomeUIComponent c = new SomeUIComponent();
    c.init();
    // I know I need to call c.setSizeFull() but I also know
    // SomeUIComponent.init() will call that, so it's fine :D
  }
}

No, that is not fine. And stop smiling. I have also done this while thinking, "I know this is not very good, but most of the instances of SomeUIComponent will be full size, so let's put that in the init method." Even if the reason sounds okay, that is still semantic coupling, my friend.

Example 2. Downcasting.

class User {
  ...
}

class MightyUser extends User {
  public mightyMethod() {
    ...
  }
}

class AnotherClass {
  public void method() {
    MightyUser u = new MightyUser();
    doThatThing(u);
  }

  public void doThatThing(User u) {
    // I know they will pass a mighty one, so let's cast it :D
    MightyUser u2 = (MightyUser) u;
    u2.mightyMethod();
    ...
  }
}

Let's cast it? You cynical developer. That is downcasting. And stop smiling again. Sometimes I catch myself thinking, "I should change the method's signature," but I find a reason no to do it. Maybe it's impossible to change the signature due to external constraints (the method is declared in an interface or superclass, for example). It might sound like a good reason, but again, still semantic coupling.

If you find something like the above while coding, look at it as an opportunity to think of a better design. There is plenty of room for improvement when you face that phenomenon called semantic coupling, a disgusting flavor of coupling you don't really want to taste. Then you can smile if you want.

Read More

Comments: A deodorant to mask code smells

Don't get me wrong. Comments are useful and not all of them have the olfactory purpose of the famous analogy I'm using in this article's title. So, what's so wrong about comments that programmers are willing to even dress a shirt about this odorous matter? Let's say we have this fragrant method:




 nastyMethod() {
  // connect to database
  ... Code to connect to the database ...

  // create default configuration
  ... Code to create the default configuration ...

  // load configuration
  ... Code to load the configuration ...

  ... and more, and more, and even more of this...
}

The problem here is that the comments are saying what the code is doing. Comments should say WHY the code is doing something, not WHAT the code is doing. Moreover, this typically leads to the Long Method anti-pattern putting in risk two basic OO design principles: Interface Segregation Principle and Single Responsibility Principle to say the less.

Make your code self explanatory:

 betterMethod() {

  connectToDatabase();

  createDefaultConfiguration();

  loadConfiguration();

}

connectToDatabase() {
  ... Code to connect to the database ...
}

createDefaultConfiguration() {
  ... Code to create the default configuration ...
}

loadConfiguration() {
  ... Code to load the configuration ...
} 

You might argue "this extract to method thing will lead to classes with too many methods, making them difficult to understand". Well, use the Extract Class refactoring if you reach that point. Remember: The object oriented programs that live best and longest are those with short methods.

Read More

Lightning fast commenting (in and out)

I have used this two or three times in my life but it's one of those simple (and useful?) hard to forget tricks. It could be useful during tough debuging times.

If you have several lines of code and you want to comment them out, you can use standard multi-line comments (this is for C++, Java, and others):

    /*
    Component contentArea = getContentArea();
    layout.addComponent(contentArea);
    layout.setExpandRatio(contentArea, 1);
    //*/

But you can also comment out the first and last lines using single-line comments:

    //*
    Component contentArea = getContentArea();
    layout.addComponent(contentArea);
    layout.setExpandRatio(contentArea, 1);
    //*/

Now you can comment in and out your code just by removing or typing the first "/":

CAUTION: Avoid usage in programmers with chronic lava flow disease, including junior and senior developers.

Read More

Empty lines and semantics in source code

I remember a couple of years ago, while working with some developers, one of them seemed to be irritated by seeing empty lines in source code. I think he was missing an important dimension of software: Readability. Grab a book nearest to you. Go ahead and do it. Grab any book close to you. Open it on any page. Are there any blank spaces between lines? If you didn't take a book for kids, empty lines will emerge like crack in the 80's making paragraphs easier on the eyes (instead of making them red). Speaking of the devil…

I feel better now*. Just as empty lines break ideas up in text books, empty lines in source code offer a new dimension for structuring code. It’s like something that the developer wants to say about the code. Almost like nonverbal communication. I’m exaggerating, but really, use empty lines to separate related lines of code when "extract method" gets to the limit.

Perfectly refactored code will have only one line per method, which is absolutely a boost in detail complexity. Don’t forget detail complexity! Sometimes we are so concerned with minimizing dynamic complexity that we end up adding tons of detail complexity. 100 methods are harder to read than 20 methods 5 times bigger if you properly place empty lines.

By the way, keep an eye on semantics, use the most suitable words for identifiers, and avoid Hungarian notation. If you need a variable to store the amount of attempts some action is performed, call it attemptsCount (or something similar with two words), don’t use things such as ac, or just count (count of what?). Saving some milliseconds on each key stroke is not as good as saving two or three days of development time plus two or three days of debugging time. Let’s do the math just for fun. When I type attempsCount it takes me like 2 or 3 times more than count. Let’s say 5 times more. If we have to type attemptsCount 1000 times and each time takes 2 seconds, we have a total of 2000s (or 33 minutes). If we have to type count 1000 times and each time takes 0.4s (2s / 5) it will take a total of 400s (or 7 minutes). Total gain using count: 26 minutes. Let’s say half an hour. Now, depending on the context, this could be absolutely nothing or way too much. Are you counting just one thing in your application? if so, count is OK, but I bet that if you are typing count 1000 times, you are counting more than one single thing. So, attemptsCount seems to be more appropriate for real life applications. Just let the code speak by itself.

And remember, it’s not only about complexity and semantics, which in turn determine maintainability. It’s also about writing code that is nice to read and good to programmers’ eyes, if you are not like the aforementioned co-worker, of course.
</rant>

* Because of the blank line, don't get me wrong! I like to keep my neurons intact... well, except for some beers every now and then. By the way, brain cells do regenerate and reproduce, even after maturity. Thanks biologists. Love you Viviana.

Read More