Learning Programming is the Easy Part

Learning programming may or may not be easy. There are many factors that determine that. If you are having fun it may be easy. If you are learning at the right pace it may also be easy. If you have a decent IQ it could also be easy. But… the reality is that it’s hard for most of us. Once we’ve done programming for a year or two it becomes relatively easy.

After tutoring over 200 students, I’ve come to the realization that learning programming can be very hard for some people. Everyone is not wired the same way and some people may just not have as much fun learning as others.

At the same time, seasoned programmers tend to take for granted the journey that got them to their level of mastery. Therefore, it all appears quite easy. One thing I’ve noticed through tutoring is that students are in over their heads many times and what works for one student may not work for the next.

Now that we got that discussion out the way, let’s assume that learning to program is easy. It probably wasn’t easy to learn, but now that we’ve mastered it, it appears that way at least. But… let’s just say it is.

By comparison, creating and maintaining applications is hard.

A significant application with volume is riddled with complexities.

I’m not going to cover each in much detail. I recommend that you google each of these topics, just to get an idea. Here is the list of complexities that you may have deal with on a real applications making working on real applications hard.

• Authentication – e.g. JWT management
• Authorization – Role-based permissions
• Dynamic Menus – All good applications need a good menu system
• Modularization – many smaller applications. This could be micro-services, subsystems, daemons or windows services
• Inter-module or inter application communication – at some point application A will need to talk to application B and vice versa
• Load balancing – Applications have to be scalable and they have to be architected in way that they can be
• Error logging – Simple as it may sound it requires understanding of a logging framework
• Performance monitoring and alerting – you need a way to keep track of how your application is behaving. A poor system is hard to search. A good system has quite a learning curve. Think of ELK here.
• Exception Handling – You can’t just litter exceptions through the entire application. You need something like Polly to break or retry.
• Endpoint Access – You will need tools like Swagger and Postman for manually testing your end points. Keep in mind that you will also need to consider them being secured.
• Design Patterns – You will need to know some design patterns to create a solid architecture for your application
• Dependency Injection – This is detrimental for unit testing. This leads you know have a good understanding of a good framework and what all the different configurations mean. E.G. Ninject, StructureMap
• Managing Dependencies – This can be a nightmare sometimes. There are package managers but that can be quite a challenge at times. (NPM, Nuget, Ruby Gems, Maven, etc)
• Use of third party dependencies – There’s third party libraries so that you don’t have to reinvent the wheel but now you must learn how to use the wheel that someone else invented.
• Data Modeling – This requires you to understand concepts like data normalization and database theory. Also you have to know how to make the OOP language talk to the database.
• Messaging – Long running processes should run on their own schedule. E.g. Rabbit MQ, JMS, etc. A good example is submitting an order. On a high volume application like Amazon your order goes to a queue and gets processed at a later time. The reason I make this assumption is because I’ve had orders get rejected long after they were submitted. If they were submitted how did they end up rejected. Well…that’s because they were only queued to be processed later. Once they were actually processed the submittal failed.
• Clean Code – Understanding of concepts like DRY, SOLID, YAGNI, and how to make your code more readable. But this also adds complexity because it may end up creating a lot more little classes throughout the system.
• Unit Testing on Complex Classes – Mocking, Assembling, Unit Test Framework
• Working with Async Processes –
• Job Queues – When you have your system talk with other systems or they have to run long running processes you need to have some time of system that can run jobs.
• Batch Processing – Similar to Job Queues could be the same.
• Understanding requirements and acceptance criteria.
• Complex Business Rules – Sometimes the main complexity is knowing what the requirements are. Others the rules make little sense at all.
• Understanding the domain you’re working in

There you go…. a big list of things that make application develop extremely hard. Most of your difficult work does not even come in those tough algorithms that your professor gave you. Most of it is just piecing things together and making them work.