When I started programming in the late 80's, there was no Internet and the word Google was not invented yet. So we resolved to books and people that knew the answers we had questions about.

I bought every book I could find on programming. Unfortunately, a book only says what it says and no more. Sometimes you are lucky, and what the book says is enough on a topic. Other times you may need the collective knowledge of a number of books to understand a topic.

Naturally, the better option was to ask someone who already knows the answers. In my case, it was a friend teaching computer science at my alma mater, which was about 120 km from where I lived. One weekend I decided to visit him and ask as many programming-related questions as I could possibly think of.

Ironically, I cannot remember anything we discussed, except this one thing he said. And this one thing has stuck with me through the years. I use it most days. So what exactly did he say to me?

He said, "Remember, computers do not do what you want them to do. They do what you tell them to do." That's it!

Yet, you have no idea how many times this has saved my programmer butt over the years. It has helped me more than anything else to solve programming errors.

Sometimes, I end up literally just starting at the code on my screen. I will get to a point where I simply cannot figure out why my code doesn't work. Sometimes, I can be stuck on this for days. Eventually I stop staring at my screen, sit back, and ask myself, "Ok, dummy, why did you tell the computer to do this if you want it to do something else?"

And lo and behold, most of the time, the answer stares me right back in the face. It's amazing how often this change of mindset has helped me find errors in my code.

And coding errors you are going to have. Lots of them. You can trust me on that one.

So, if there is one thing only you take away from this website, make it this little piece of advice.

By the way, I literally have problems with dry eyes because of all the starting at the screen over the years. Apparently, programmers do not blink enough, which ends up damaging their eyes. So, please, blink regularly so your eyes can get the necessary lubrication.

I know it sounds like a cliché, but the idea was to build the courses I would have loved to learn from when starting out. Something that guides me one step at a time, leaving no gaps in the process. Here is what I mean...

You decide to learn to program and pick the JavaScript language, for example. Next, you buy the Learn JavaScript in Thirty Days course and you start learning. After a while, things are getting difficult, all the while you have not yet fully comprehended the beginning parts as well. Soon you quit the course and decide that life is too short for this sh*t.

My son, who is also a software developer, while at university, helped during a "Learn Python" day session. His job was to help people install Python and help when the code didn't do what it was supposed to. By the end of the day, the attendees built an app that could do an API call to their Facebook profile. Those attendees paid lots of money for that session. They were cheated into thinking they could learn Python in a day. Most attendees did not know how to install software. Needless to say that they had no idea what an API was. My son was so disgusted with the whole process that he never returned to assist.

So what went wrong here? Simple! They progressed way too fast. We need time for things to settle in our brains. Although we have technically unlimited storage space, we do not have unlimited energy. Most of us can focus for three hours a day. Five hours max!

So, when learning new things, we have to learn in small chucks. Each chunk needs to make total sense. And each chunk must be linked to stuff already known. Remember associative learning?

This is how I intend to teach you. One small thing at a time. You will know what to learn, why you need to learn it, and you will learn just enough for the job at hand.

The Becoming a Programmer Series is focused on progressing slowly while leaving no gaps. So, once you have worked through my series, those other online courses will make a lot more sense for you. It's just wise to build a solid foundation before you start building the walls and roof.

So here is a short list of people I think may benefit from my method:

• You want to go at this on your own with no intention to attend university.
• You are planning to study computer science at university but need a thorough introduction into the world of programming.
• You are curious about what this programming thing is all about.
• You are already learning to program but find that there are things that do not make sense, and you need to fill in the gaps.
• And, of course, everybody else who wasn't mentioned above.

1. Where do I start?
2. What do I learn?
3. When do I know enough?
4. Where do I go next?

The short answer is, "You need a roadmap!" And not just any old roadmap. You need a roadmap that will answer all four of these questions. This roadmap will tell you:

1. What topic to start with
2. What about that topic you need to know
3. When it is time to move on to another topic
4. What topic to move on to next

So, where are you going to find such a roadmap? Glad you asked! It just so happens that I have developed such a roadmap. I call it The Becoming a Programmer Series. And you will find that roadmap in the Tutorials section of this website. How is that for convenience?

I will take your hand and lead you step by step through your journey. I have the benefit of knowing stuff that you don't know yet. So I can show you the smart cuts to take. Remember, no shortcuts, just smart cuts. This way you will only learn the things necessary to do the job at that particular point in time. If the next job requires new skills, we will add new information to your existing knowledge base. Thus, no, information overload!

The other important thing is the order in which you will learn things. I have designed the lessons in such a way that each new thing you learn will build upon what you have learned already.

For example, let's say the goal is to build a web application to capture your piano practice sessions. As this is a typical Information System, you know there will be three layers. You also know that the database is the most important, because without a database, there is no app. So, the Becoming a Programmer series will first teach you everything you need to know to design and build the database. After that, you will learn how to build the business logic for such an app. Once you can do how to build the business layer of the app, you will learn how to make this business layer 'talk' to the database you created earlier. That, by the way, requires a different skill set than the skill set required to build the business layer. Once the business layer is complete and can can communicate with the database, it is time to build a user interface. Once the user interface has been built, you have to learn how to make the user interface 'talk' with the business layer of the app. Once again, that requires a different skill set.

As you can see, there are at least five layers in your app:

1. The Database Layer
2. The Business Logic Layer
3. The Data Access Layer
4. The User Interface Layer
5. The Business Access Layer

All five of these layers require a different skill set, and we will also learn things in the order above.

On top of it all, you will learn different technology stacks. A technology stack is a combination of the programming languages, frameworks, libraries, databases, and build tools you are using to build an application. This list is not exhaustive, but it gives you a good idea that there is a bit more to software development than meets the eye initially. Also, don't worry about any of the terms mentioned. Eventually, they all will make sense.

Let's say we are going to use Java to build our music practice log app. We will then pick the following technology stack:

• Java programming language
• PostgreSQL database
• Spring Boot Framework
• Gradle build tool
• Git version control
• Hibernate JPA implementation
• Spring MVC framework
• Spring Security
• Apache Commons Lang library
• Eclipse IDE
• JUnit for unit testing

And so the list goes on and on...

If you decide to build the app with C#, your technology stack will look different. Same goes for JavaScript or Python. Different stacks each time.

I guess a fair question would be, "Who decides what goes into a technology stack?" The answer is a typical IT one. It depends! On what you ask? On things like project requirements, team expertise, scalability, performance, development speed, time-to-market, budget, maintenance, and component compatibility to name a few.

Luckily for us, many of these decisions have been made for us by the developers of frameworks. Thus, if we decided to use a particular framework, most of the technology choices have been made. Especially with what is called opinionated frameworks.

Any way, much more of this later in the series.

All you need to take away for now is that there is help available to become a programmer in the form of The Becoming a Programmer Series found in the Tutorials section of this website.

To become a programmer, you need to know a lot of things about a lot of things.

But before you can know a lot of things, there are four questions that need answering first:

1. Where do I start?
2. What do I learn?
3. When do I know enough?
4. Where do I go next?

Where do I Start?​

This is probably the most challenging question to figure out if you are a newbie. At this stage you simply do not know enough to make an informed decision.

What do I Learn?​

Let's say you know where to start. Let's say you decided to start with the Java programming language. Java is vast! What exactly do you learn? You can't learn everything there is about Java.

When do I Know Enough?​

Again, let's say you figure out what area of Java to focus on, when do you know enough of that specific area?

Where do I Go Next?​

Once again, let's say you have figured out what and how much to learn, where do you go next?

These are the typical issues you will face when starting out. The good news is that there is a solution to this problem, and we will look at that in the next post.

How do I Become a Programmer?​

This is a loaded question! Unfortunately, an online search may give you something like the following suggestion:

• Pick a programming language
• Do some courses covering that language
• Write some small apps
• Apply for a programming job

While this is not necessarily wrong advice, it is so full of gaps that it is practically useless.

The above suggestion raises a number of questions. For example:

• What programming language should I pick?
• Why that particular language?
• What courses should I take?
• Why those courses?
• What type of apps should I write?
• Why those types of apps?
• When am I ready to apply for a job?

When starting out, you unfortunately don’t have the knowledge to answer any of these questions. Hench this website where you will find a proper answer to the question, "How do I become a programmer?"

From Zero to Software Developer​

We will start out assuming that you know nothing about programming. We will take things one step at a time.

Your first transition will be from Zero to Coder, then from Coder to Programmer, and finally from Programmer to Software Developer.

It is sort of obvious from this statement that a Software Developer knows more than a Programmer, who in return knows more than a Coder, who in return knows more than Abraham Lincoln about programming.

Now these transitions are really just a matter of scope rather than depth. There are so many skills that you need to develop that we cannot go into them too deeply. Also, it is counter-productive to go too deep into the topics we’re going to focus on. For example, you don’t need to know everything about Microsoft Word to write a resignation letter. You need to know only the very basics.

There was a lady working for one of my clients who used Microsoft Word for years without knowing how to save the documents. She simply printed each letter and stored it in a filing cabinet. Sometimes we can get quite far with limited knowledge, on the condition that it is the right knowledge at the right time.

However, the important reason we are not going into things too deep is threefold:

• As you are going to learn a lot of new things, I want to prevent information overload.
• YAGNI is short for "You ain’t going to need it!" So, we don't want to spend time learning things that are not needed at that particular point in time.
• Similarly, learning unnecessary things will just slow us down.

So, instead of becoming a master in one particular skill, you will rather develop a broad set of skills, knowing just enough per skill for that particular point in time. We will, however, revisit each skill and expand on it when needed.

Disclaimer​

I guess a disclaimer is in order here. I am a Fullstack Software Developer, and my forte is designing and building Business Information Systems. This is what I can help you become. Fullstack just means that I am capable of building the whole application, from the User Interface (aka the Frontend) all the way to the Business Logic and Database (aka the Backend).

I cannot teach you how to build computer games or operating systems or compilers, for example. Also, my native mobile app and Internet of Things (IoT) skills are limited as that’s not where my focus is. That said, I am sure you will find resources online should you desire to focus on those areas instead.

Business Information Systems​

Business Information Systems are applications that support the operations of businesses by recoding daily routine transactions, such as sales, for example. You will find these in most businesses. Examples are Point of Sale applications, Banking applications, Insurance applications, e-commerce applications, HR systems, ERP systems, etc...

Please note the interchangeable use of the terms Application and System. Let’s briefly look at these applications/systems in a more academic way.

Information Systems​

Business Information Systems fall under a category called Information Systems. Let’s briefly look at them by grouping them in two categories, Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP) systems:

Online Transaction Processing (OLTP)​

These systems are transaction-oriented and are used to record the daily transactions of a business. These transactions can be financial or non-financial of nature. These Transaction Processing Systems are very detail-oriented and are the entry point of a business’s data. They usually consist of various data capture screens. Although they capture all the business data, they are typically non-analytical in nature. Thus, reports generated by these systems tend to be detailed as they are generated with transaction-level data. These applications also regularly interact with third-party applications such as sending text messages, email, or communicating with banking systems to name a few.

Online Analytical Processing (OLAP)​

These applications take the data generated by the Transaction Processing Systems (TPS) mentioned above and are used for decision-making. These are called Management Information Systems (MIS). Management Information Systems are in turn broken into more types such as Decision Support Systems (DSS) and Executive Support Systems (ESS).

Please feel free to read more about these online as we will focus on Transaction Processing Systems (TPS).

Conclusion​

The above information should give you an idea of where the focus of this website will be. You will encounter Business Information Systems in your daily life with every business you deal with, so I believe it to be a good skill set to have when becoming a programmer.

Unfortunately, seeing that we’re just starting out, we’re facing a number of problems. We will discuss this in the next post.

This extra degree came in handy when I did my 2-year compulsory military service from 1988 to 1989. This placed me in the privileged position to help set up a Therapeutic Drug Monitoring (TDM for short) clinic at an academic military hospital.

Certain drugs have narrow therapeutic indexes. With these drugs, it is important to individualize dosages so they work as effectively as possible. This also means that just a little higher dosage may be toxic and just a little lower dosage may be subtherapeutic.

To calculate these exact dosage per patient, one uses mathematical modeling, taking various parameters into account. That meant that we really hit the calculators a lot. And working with manual calculators, also introduced the possibility of errors, which we obviously had to avoid at all cost.

The decision was made to develop a software application that will do the calculations for us and also store the information for future retrieval. As I was working closely with the programmer, I decided, "I like this! I also want to program."

A friend from university introduced me to the dBase programming language using the Clipper compiler, and so my new career started. By the way, this was before there was a thing called the Internet, and Microsoft Windows also did not exist. It was MS DOS all the way!

After my military service, I managed a hospital pharmacy and built a Stock Order and Management System that reduced our stock levels from 7 months to 28 days. As a result, we won the Pharmacy of the Year award out of 49 private hospital pharmacies. I guess that was when I realized that I could make a career out of programming.

Because of this award thing, I was headhunted by a private hospital group and joined then in January 1995. Also, in January 1995, I got my first client, an Underwriting Management Agency (UMA for short). A UMA is a business that does all the work, such as policy underwriting, premium collection, claims handling, and claims payments on behalf of the insurer.

The hospital group bought a Managed Healthcare business in desperate need of a new software application. I jumped in and in 4 days, I wrote them a temporary application with Microsoft Access. I wrote the proper application for them over the next year with the Delphi IDE, (short for Integrated Development Environment), which is using the Object Pascal programming language. By that time we Microsoft Windows 95 just launched.

For the UMI, I built their first applications also with Delphi.

Java was introduced in 1995. So I started to build some applications for the UMA with Java.

In 2000, Microsoft released the C# programming language. I remember when I started to work with C#, I one day said to a colleague, "Look, they fixed Java!" That said, Java was eventually fixed, and I love working with both Java and C#.

In 1996, I found two new clients. The one client was a dentist that worked for a major private medical scheme. It was an interesting application as it was, among other things, checking how many times the same tooth has been pulled. I am not even kidding here. Some dentists would charge the medical schemes multiple times for the same patient and the same tooth.

The second client was the national branch of an international emergency services company. These guys needed better software to track all the roadside assistance they provided, and again, Delphi to the rescue. Then one day, about two years in, they fired me. Apparently the international company decided to standardize their system across countries.

Eventually, the work I did for the UMA became a full-time job. Thirty years later, I am still building all their applications for them

I am telling you all this to show that I have learned a thing or two in the process.

The two most important things I have learned are:

• to keep things simple
• to keep things practical

These two things, simple and practical, are close relatives. Please note that simple does not necessarily mean easy. On the contrary, sometimes it takes effort to find simple solutions.

So, during these tutorials, we will keep things both simple and practical so you can be prepared for the real-world scenarios out there.

Hopefully, I can help you become a programmer in the shortest time possible. That said, there are no shortcuts, only smart cuts!

You will still have to put in the hours. It literally took me years to learn this stuff. But it is an awesome ride!

My name is Deon Slabbert, and I am a Fullstack Software Developer.

I have been a full-time, Fullstack software developer now for the last 38+ years, and I hope to teach you how to become a Fullstack software developer as well.

I build Line-of-Business applications, also known as Enterprise applications, and as such, my focus will be on these types of applications. I will most probably call them Business Information Systems as I find that to be a good descriptive term for these types of applications.

So what exactly is a Fullstack software developer?

Fullstack Software Developer Defined​

Business Information Systems typically consist of three layers, the User Interface Layer, the Business Logic Layer, and the Persistence Layer.

User Interface Layer​

The User Interface Layer is typically the part of the application the user interacts with. If you decide to buy something online, you will use the Amazon website, for example. Everything on that website you see and interact with, like typing search criteria or clicking buttons, is called the User Interface.

Now, for most users, the User Interface is the application, as they don't know or care what happens behind the scenes when they click a button.

Business Logic Layer​

Then there is the Business Logic Layer which is not visible to the user. This is the behind the scenes part of the app where the number crunching takes place. The better name for the number crunching is Business Logic. In our Amazon example, this is where the shopping cart is filled with items and order totals are calculated. Now, it is important that this shopping cart with its items is not getting lost once the user closes the browser. Say hello to the database!

Persistence Layer​

The Database Layer or Persistence Layer represents the section where all transaction data is stored for future retrieval and manipulation. This is also the most important section of the Business Information System because this section represents the so-called source-of-truth of the business. Without the data, there is no business.

Skills Required​

For each of these Business Information System layers, you need different skill sets. So, starting with the Persistence Layer, then the Business Logic Layer, and finally the User Interface Layer, I teach you everything you need to know for each of these layers.

I start from the assumption that you have never written a single line of code before. From there we keep moving forwards, one step at a time. We keep linking new information to existing knowledge, which will speed up the learning process substantially. I call that associative learning.

Now I know that this is an ambitious goal, but I will do my very best to keep adding to the existing content in an orderly fashion.

Let's now see how this website is organized. You will see that there are two sections, namely Courses and Blog.

The Blog Section​

In the Blog section, you will find general information and code snippets. The code snippets will be mainly in Java, C#, SQL, HTML, CSS & JavaScript. These code snippets are sample code that I find useful in my day-to-day job, and I use it as a quick reference. But because I often use it, It may be of help to you too.

The Courses Section​

This is the main body of knowledge. Here you will find everything you need to know to become a Fullstack Software Developer one step at a time. The layout is designed to help you not skip a single step. You start at the very top and work your way down.

Finally, why should you listen to me? I will discuss that in the next post.

The application.properties File​

mode=development

The Java File​

@Value(value = "${mode}")
private String mode;

Reading from Text File​

var fileName = Path.of("myfile.txt");
var content = Files.readString(fileName);

Writing to Text File​

var fileName = Path.of("myfile.txt");
var content  = "this is a test";
Files.writeString(fileName, content);

SELECT​

public int test() {
    var sql = "select count(*) from product";
    return this.jdbcTemplate.queryForObject(sql, Integer.class);
}

public int test() {
    var sql = "select count(*) from product where name = ?";
    return this.jdbcTemplate.queryForObject(sql, Integer.class, "Joe");
}

public String test() {
    String sql = "select name from product where id = ?";
    return this.jdbcTemplate.queryForObject(sql, String.class, 1212L);
}

public MyProduct test() {
    var sql = "select id, name from product where id = ?";
    return jdbcTemplate.queryForObject(sql, (resultSet, rowNum) ->
            new MyProduct(
                    resultSet.getInt("id"),
                    resultSet.getString("name")
            ), 123);
}

public List<MyProduct> test() {
    var sql = "select id, name from product";
    return jdbcTemplate.query(sql, (resultSet, rowNum) -> new MyProduct(
            resultSet.getInt("id"),
            resultSet.getString("name")
    ));
}

private final RowMapper<Actor> actorRowMapper = (resultSet, rowNum) -> {
    Actor actor = new Actor();
    actor.setFirstName(resultSet.getString("first_name"));
    actor.setLastName(resultSet.getString("last_name"));
    return actor;
};

public List<Actor> findAllActors() {
    var sql = "select first_name, last_name from t_actor";
    return this.jdbcTemplate.query(sql, actorRowMapper);
}

INSERT​

this.jdbcTemplate.update(
    "insert into t_actor (first_name, last_name) values (?, ?)", 
    "Leonor", "Watling");

UPDATE​

this.jdbcTemplate.update(
    "update t_actor set last_name = ? where id = ?", 
    "Banjo", 5276L);

DELETE​

this.jdbcTemplate.update(
    "delete from t_actor where id = ?", 
    Long.valueOf(actorId));

OTHER​

var sql = "create table mytable (id integer, name varchar(100))";
this.jdbcTemplate.execute(sql);