New developer trail

new developer trail thumbnail

As a software developer who is starting out there are going to be a lot of challenges that you will face throughout your day. There are going to be expectations too that you must meet from your fellow software developers.

Wouldn’t it also be nice to be productive in your day to day tasks?

I think it’s essential to learn the fundamentals of software development in order to boost your productivity and improve your skill of writing good code.

Here’s a list of things I think all software developers should know when just starting out.

Writing clean code

Writing clean code is the most important thing for you do as a software developer. Writing that has meaning and is easy to read is a reflection that you put care into your craft.

Clean code will allow you to look at the code and just understand the procedures describing it by glancing at it, not having to struggle to figure out what the hell it’s doing by digging deep into obscure methods or having to build up your memory of activities that occur when reading someone else’s code.

Clean Code by Robert C. Martin is the first book you should read and own as your bible to writing that is clean and easily readable.

Solid principles

SOLID is actually an acronym. * Single Responsibility Principle * Open/closed Principle * Liskov Substitution Principle * Interface Segregation Principle * Dependency Inversion Principle

These are the basic rules that govern how you design objects.

Single Responsibility Principle ensures that a class should have only a single responsibility. Your AccountService class should only handle account related stuff, don’t introduce concerns about posts of any other content. To ensure you maintain the Single Responsibility Principle you can structure your application in layers and split the classes into smaller ones.

Open/closed Principle states that software entities (classes and modules) should be open for extension, but closed for modification. In some cases you’ll have a change in requirements or wanting to add new behavior and your previous classes would require change. But they don’t have to change. You should design your classes in a way that you can easily extend their behavior without changing the inner working of the class itself. This can be achieved with dependency injection, the strategy pattern or with behavior parameterization.

Liskov Substitution Principle states that an object in a program should be replaceable with subtype instances without affecting the correctness of the program.

If we were to create an interface, UserRepository, and concrete classes that implement this interface, MongoUserRepository, and JpaUserRepository. MongoUserRepository should be easily substitutable for JpaUserRepository. This change should not affect the correctness of the program.

You should be able to easily substitute one class for another of the same type.

Interface Segregation Principle states that many specific interfaces are better than one big interface. An interface is a contract. Instead of forcing a class to implement a bloated contract, make it instead implement specific contacts (interfaces) that it’s interested in.

Dependency Inversion Principle is my favorite principle. Abstractions should not depend upon details. Details should depend upon abstractions.

Interfaces (abstractions) should not depend on concrete classes, rather they should depend on other interfaces. Your UserService should depend on an abstraction, so you can easily substitute your concrete implementation. (LSP).

SOLID principles shouldn’t require you a book to learn, but just a day of reading blog posts and you’ll know it.

SOLID principles on Medium

Object-Orientated Programming

Do you really understand OOP? I didn’t for a while. Until I read Streamline Object Modeling.

When building something I often found it difficult to come up with objects and developer their attributes and relationships with other objects. This is what this book is about.

It is important for you to first understand that most systems are built around a business’ persona and to think that each part of the application works as a department of a business.

The HR department is responsible for managing employees, managing employee contracts and hiring new employees. How would you model such a department in term of objects? How do the relationships work between objects? What kind of actors do I want to involve? What kind of services do I want to create?

The all fall under your skill to select objects and build relationships between them and handle their actions.

Streamline Object Modeling by Jill Nicola is a must read for any software developer wanting to master the understanding of Object-Orientated Programming.

Test-Driven Development

You should really master this methodology. You should know who to write unit tests and know all the principles that are a part of TDD.

TDD simply is an interactive process to writing code that works and is clean. Unit tests also ensure that the behavior of your application stays consistent when introducing new features.

TDD follows a feedback process. 1. Quickly add a test. 2. Make it compile. 3. Run this test to check that it fails. 4. Make it run (make it pass). 5. Make it right (refactor to clean code).

Using this approach can improve your productivity significantly. * The things you should learn are the TDD rhythm. * Triangulation

How I learned TDD was by the inventor himself, Kent Beck in his book Test-Driven Development by Example

You can read more about TDD in my blog posts: * Test-Driven-Development Tutorial: Writing your first unit test * TDD Rhythm Explained with Exercise * Introduction to Test-Driven-Development (for an in-depth guide)

Git (The modern VCS)

Git is your friend. If you don’t understand how to use it properly you can feel like ripping your hair out and screaming!

Git is a Version Control System (VCS).

Git is basically a differential backup program for files, and a VCS user interface written on top of it. What this means is that you can version your source code by taking snapshots of the source files. As you progress in writing new code you can snapshots. When you mess up you can easily revert back to a previous state of the code.

A VCS like git can greatly improve your productivity when working on features or bug fixes. It’s important to know the basic concepts of git to achieve this productivity.

Learn Git!

One book to help you do this is Pro Git by Scott Chacon

Pick one database

Yes, it’s fun to play around and use different databases. But what will you really gain? A whole lot of confusion, really.

There are fundamentally five different types of databases and all have there use cases.

  • Relational database
  • Document database
  • Column-family
  • Key/value database
  • Graph database

The top two most used types are relational and document databases. Pick either of the two types. You can decide based on the one you use the most frequently at work.

In my case, we use MongoDB which is probably the most popular document database. To learn mongo I will go an learn the basic CRUD operations, and how indexes work. Maybe later look at transactions which was just recently implemented.

If you are wanting to learn a relational database like MySQL or Postgres, then, learn the basic CRUD operations. Learn how to create Indexes, and how to use JOINS and create transactions.

That’s it. Spend a few months on the one and then when you’re happy with your competency, move onto another.

Learn one framework

At work, we use a Spring Framework. When I started I just knew the basics of Spring. It wasn’t until I actually bought a course on Udemy and learned the all the features the framework has to offer, did I understand how to use it.

Learn one framework well. Understand it and get to a point where you can build an application with it by yourself.

What I have learned is that when you learn something well enough and you when you move onto learning something new, you experience with the thing you know pretty well usually transfers. This is because a lot of things in frameworks are usually similar. All dependency injection frameworks are built on the Dependency Inversion Principle. Once you learn one, besides semantics, pretty much all of them are the same.

To learn a framework well, I suggest buying a course online that teaches you the framework by building real-world applications.

Learn one language

It’s important to stick to one language and learn it well. That way you’ll develop the intuition to know what works well for the problem at hand.

Start learning the programming language constructs such as: * Classes * Interfaces * Types * Iteration * Exceptions * Generics

Learn class design

When learning the programming language constructs you should be able to exercise the SOLID principles effectively. Learn how to build abstractions effectively so that you could design a few collaborating classes that achieve an objective but doesn’t interfere with the Open/Closed principle or any of the SOLID principles for that matter.

Learning the SOLID principles together with the programming language will allow you to make sense of things like Interfaces and abstract classes which are crucial to object design and reuse.

Knowing how to design classes using the SOLID and Object Modeling principles is going to be the most important thing for you to learn first.

Learning the SDK

The thing that will probably take the longest to learn is the SDK that the programming language has to offer.

A programming language like Java includes the Collections framework that provides a whole bunch of generic data structures. The Java SDK also includes Date and Time APIs, the Streams framework for aggregating data, and database connectivity.

You want to get to a point where you know the programming language well enough to be able to build an application with it and use the given tools in the SDK to help you do that.

Read books, please!

I think the only way to become better is to read software development books.

There different types of books, ones that are fundamental in nature and are timeless and other books that are framework/technology specific.

The important thing is that you need to motivate yourself to say I’m going to become good at this specific subject. You actually need to sit down and study the theory and appreciate.

Timeless books

Clean Code by Robert C. Martin is a timeless book on writing code that is easy to read and better to maintain.

Test-Driven development by Example is an excellent book by Kent Beck

Streamlined Object Modeling is also another timeless book which will teach you object-orientated programming.

You’ll probably spend a lot of time when you start out reading fundamental books like these to learn the concepts found clean code and test-driven-development.

Technology specific

But then there are more technology-specific books like Spring in Action, which is a book about the Spring Framework. Or MongoDB: The Definitive Guide, which are usually nice easy to read books.

In my experience reading technology, specific books used to be difficult for me to read and understand. This is because I didn’t have any experience playing around with a specific technology. Once I first played around and used a technology, I would later go and read a book about it. These books are useful for when you have experience with a technology but you want a deeper dive into understanding it, going back to a start line and letting an expert teach you.

Conclusion

Learning the fundamentals takes the longest. This was explained to me by my manager at Zailab. Do you ever notice that when a company starts construction on a company the foundation always takes excessively long to get done right? Once the foundation is built the rest of the building just shoots up within a few months.

This is always how you should approach your learning. It will be frustrating to learn all this. I’m in fact still in this phase as a junior Java developer. So embrace this and just get your fundamentals right because you will build on top of this.

Adrian van den Houten

I'm Adrian van Houten, founder of ScholarCoder and a passionate software developer for full-stack web development. Read more about me here.