Welcome to Better Java Academy where I’ll teach you how to become a Senior Developer in the application programming space.   My perspective is that of a developer that has worked mainly at Fortune 500 companies where I’ve developed and maintained internal and external systems especially ecommerce, financial and inventory applications.

From my experience, application programming is different from software engineering as applications, particularly those at large companies, tend to be about data and applying mostly conditional logic to that data.   On the other hand, software engineering tends to be about creating applications that have a specific purpose that is often sold widely to many companies such as Microsoft Excel or a trading application.

Applications at Fortune 500 companies tend to be proprietary and specific to what the company does.  For example, a healthcare company such as Anthem most likely uses a claims system that differs from that of United Healthcare.   The main reason for companies to do this is to be able to customize their own application to gain an efficiency or meet changing demands of the business environment.

The trend in most large organizations now is to use both software that is purchased and combine it with applications.   Using ecommerce as an example, it’s quite common now to have the payment part of the system be handled by a purchased piece of software that integrated with a company’s ecommerce application.

A Word on Learning itself.

Any journey where you’re trying to improve your skills requires that you first understand how learning works, so I want to spend a little time walking through the process of learning as I will refer to learning’s characteristics throughout the course.  

💡
There are six aspects to learning and they are: 1. knowledge, 2. constraint, 3. perspective, 4. context, 5. failure, and 6. repetition.

Knowledge is something that is imparted to you in various formats.   Textbooks, online courses, stackoverflow (a developer’s favorite resource).  In my view, this is the simplest and easiest form of learning that is widely available.   Let’s say you need to go from New York to Boston.   You’re probably going to check Google Maps for travel distance and travel options.  You may also check bus schedules, car rental options, flights and hotels.   Similarly, if you have been programming Java, you’re probably going on various websites or using an IDE to check method signatures, examples, etc.   But knowing something is not enough to become good at it.   You can’t take a class on Judo and become a black belt.   So let’s take a look at the other aspects.


Constraint is the limitations or barriers you need to consider while trying to achieve a goal.  Going back to the New York to Boston trip, what if you had to go there and back in a day or what if you only had $500 to spend.   Similarly, applications have many such constraints within an organization that the Senior developer has to navigate.   With the complexities of today’s systems, it seems to me these constraints often contained in tribal knowledge are one of the biggest hurdles developers have.    Some of the ones I personally have come across withing Java are using only https communication, being limited to a particular Java version, limit reading of database records to 10000 at a time.   Other aspects of corporate IT constraints include cloud vendors, security policies around open source, authentication, and legal requirements.


Perspective allows you to see things in way you normally wouldn’t get from simply knowledge alone.  It comes from communicating and collaborating with others who can look at facets from a problem from different angles.   To use the earlier analogy of a trip from New York to Boston, a person who frequently travels the route would be able to give you keen insights into the journey.   For example, he/she may know about traffic while driving, or be aware of the cheapest flights, best road routes, great coffee shops along the way, and attractions in Boston that may be of interest to you.    In programming, it’s important to talk about your code or solution with other developers with varying degree of experience.   As a Senior Developer, I’ve open advised other programmers around defensive programming to account for failures in production because I bring years of experience to the table.   I’ve seen some epic fails in my time not because of programming quality but other issues the developer failed to consider.


Context is main driver of what you’re trying to solve with programming.   Learning is far more relevant if you understand all the nuances of the issue.   Earlier in my career, I worked on converting a client server system into a browser-based web application for a large call center.  One of the requirements was to implement a “Cancel” button so that the agent taking the customers call could cancel the transaction and have the customer’s information go back to its original state.   Back then, UI capabilities in browsers were rather limited and HTML didn’t allow for a cancel button.   I needed more context about the issue so I walked over to the call center floor to observe a customer services agent as she was talking to the customer.   In this particular application, consent had to be given by the customer for the agent to even see the customer’s data.   The first rendering of the customer screen had to appear in the read only state to prevent any modifications.   Once the agent pitched the customer for a sale or additional service to their account, the agent needed a “Edit” button which recorded served to make the screen editable as well as capture consent from the customer.   If the customer agreed to the sale, the agent could submit the new information.  If the customer disagreed, the agent needed a Cancel button to both record that the customer did not take the offer and put the screen back to its original state.   Only when I understood this context of the call center application properly was I able to design and program the screen dynamics properly in HTML and Java.  I ended up picking GWT as a UI framework to meet these requirements vs plain HTML.   Going back to our travel analogy, looking at the context of the trip from NY to Boston, I’d want to know what is the reason for this trip.   Personal or pleasure?  How much time do I have to spend there?  What sights should I see?   Where’s the best seafood restaurant.   Do I have friends there that I haven’t seen in a while?


Failure leading to learning doesn’t need a lot of explanation.  In the words of Yoda, “The greatest teacher failure is” is very, very true statement especially in programming, and IT in general.   The DevOps culture is all about embracing failure.  Fail fast and often.   I’ve seen a lot of Java code fail in production even after unit tests and functional testing.   You can’t become a Senior Developer until you’ve triaged production failures.    My first experience with failure was on a Java – JDBC based application that had a lot of SQL calls to an Oracle database.   A long running query from an unrelated application caused all the calls from JDBC to exhaust the connection pool on Weblogic.  The Java application subsequently ran ouf of memory.


And finally, you can’t learn anything properly without repetition.   Just like a muscle can’t grow simply by lifting a weight once, your programming muscle memory won’t grow without writing lots of code repeatedly.   Write code, and write lots of it especially earlier in your career.  Try and create applications in the space that you are interested in outside of work.